emkis / gtm-event-tracker Goto Github PK

Description

I want to make sure I can use all the features in different ways, and that everything is working correctly.
Right now I just have Unit Testing, so integration tests are necessary.

Description

There is no way to get the current value of a context, so this makes it harder to update its value with setProps. If you want to update its value with the same properties you need to provide them manually or from a function return.

Proposal

import { createTrackerContext } from 'gtm-event-tracker'

const trackerContext = createTrackerContext({
  userId: 'no id defined',
  leadId: 'kip-pqu-hrc',
})

trackerContext.setProps(previousProps => ({
  ...previousProps,
  userId: '123',
}))

Description

I want to know how much of the codebase is being tested, and what is the code coverage.

Proposal

• Set up Jest code coverage configurations
• Look for a Github action that comments on the difference in coverage in PRs

Description

I want to improve the documentation of this library.

I need to include

• Examples
  • CodeSandbox (for trying out the auto-completion)
  • React
  • Vue.js 3
• Include Examples section on README.md

Description

I want to create a README.md file that describes how to use this library.

I need to include

• Installation
• It depends on GTM
• Why?
• Concepts
• Server-Side Rendering (SSR) caveats
• API Surface

Description

I want to be able to configure Logs to change some behaviors based on my needs.

Use cases

• Enable or disable logs based on the environment or anything else
• Control the levels of logs that are triggered

Proposal

import { configure } from 'gtm-event-tracker'

configure({
  logger: {
    debugAll: true,
    debugEvents: true,
    debugContext: true,
  },
})

Description

I think it's more clear if the name of the options related to the Logger begins with "log" instead of "debug".

And would be interesting to be able to disable the push to the targetProperty, for local development use cases.

Proposal

import { configure } from 'gtm-event-tracker'

configure({
  logAll: false,
  logEvents: false,
  logContext: false,
  disableTargetPropertyPush: !isProduction,
})

Fixes

• (configuration) Tornar os LoggerOptions opcionais

Features

• (data-layer) Aceitar o targetProperty da configuração global
• (configuration) Adicionar novas opções de configuração para o DataLayer
• Pensar sobre como validar se os logs devem ser disparados ou não (loggerManager, loggerMiddleware?)

Refactors

• (data-layer) Alterar o assertIsAvailable para isTargetPropertyAvailable
• (data-layer) Validar targetProperty apenas uma vez
• (data-layer) Validar targetProperty apenas quando chama o addEvent()
• (with-tracker) Remover a chamada do isTargetPropertyAvailable antes de chamar o trackEvent
• (tracker-context) Remover a opção debug do TrackerContextOptions

Tests

• Garantir que os logs estão sendo chamados ou não onde deveriam
• Adicionar testes de integração

Configs

• Adicionar processo de bundling com o Rollup
• Adicionar opção engines pra delimitar a versão do Node.js no package.json
• Entender o que usar na opção sideEffects no package.json

Description

I want the DataLayer module to be more independent. Today it depends on window.dataLayer directly and this is not great because some users may want to push the events in a different array, or they may want to have full control over the push handler.

Use cases

• Enable the module factory to depend on an external array/object (this improves the testability)
• Provide an option to control the event push handler

Proposal

import { configure } from 'gtm-event-tracker'

configure({
  events: {
    // the default value should be window.dataLayer
    targetProperty: window.myCustomDataLayer,

    // a function that can modify event object before push it to the `targetProperty`
    transformer: (eventProperties) => {
      const formattedProps = changeObjectKeysToKebabCase(eventProperties)
      return formattedProps
    }
  }
})

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Description

I need to create labels that make sense for this project, to help me and anyone who wants to contribute