isConnected becomes true before connectedCallback() is called

You can't rely on isConnected to determine if connectedCallback() has already been called:

connectedCallback() {
  this.foo = 'bar'
}

doSomething() {
  if (!this.isConnected) return
  console.log(this.foo) // 'bar' | undefined
}

If you have code that should only ever run after connectedCallback(), you probably want to set your own flag:

connectedCallback() {
  this.foo = 'bar'
  this.isInitialized = true
}

doSomething() {
  if (!this.isInitialized) return
  console.log(this.foo) // 'bar'
}

attributeChangedCallback() is also called on attribute initialization

attributeChangedCallback() is called after each observed attribute is initialized once the element is parsed, even if those attributes never change:

<my-element foo="bar"></my-element>

attributeChangedCallback(name, oldValue, newValue) {
  console.log(name, oldValue, newValue) // 'foo', null, 'bar'
}

The good news is, all initialization calls happen before connectedCallback(). If you only want to respond to actual modifications, you can once again check if connectedCallback() has been called:

connectedCallback() {
  this.isInitialized = true
}

attributeChangedCallback(name, oldValue, newValue) {
  if (!this.isInitialized) return
  console.log(name, oldValue, newValue) // unreachable during initialization
}

observedAttributes can be used as a (property) initializer

The observedAttributes static property is accessed before any attributeChangedCallback() calls. This means you can hook into it to, for example, dynamically create a property for each attribute before attributes are initialized:

static createProperties(attributes) {
  const store = {}

  // map attributes to properties
  attributes.forEach(attr =>
    Object.defineProperty(this.prototype, camelCase(attr), {
      get() { return store[attr] },
      set(value) { store[attr] = value },
    })
  )

  // ensure properties are only created once
  this.createProperties = function noop() {}
}

static get observedAttributes() {
  const attributes = ['foo']
  this.createProperties(attributes)

  return attributes
}

attributeChangedCallback(name, oldValue, newValue) {
  this[camelCase(name)] = newValue
}

connectedCallback() {
  console.log(this.foo) // 'bar'
}

Wrapping up

I'm sure there are other edge cases I'm not taking into account, and maybe I shouldn't be using connectedCallback() in the first place. Hopefully this related WICG discussion leads to improvements to the Custom Elements specification.

The secret is to use Vite's library mode, and externalize all dependencies and built-in Node.js modules so that they are not bundled with your code:

// vite.config.js
import { defineConfig } from 'vite'
import dts from 'vite-plugin-dts'
import pkg from './package.json' assert { type: 'json' }

export default defineConfig({
  build: {
    lib: {
      entry: './src/index.ts',
      formats: ['es'], // pure ESM package
    },
    rollupOptions: {
      external: [
        ...Object.keys(pkg.dependencies), // don't bundle dependencies
        /^node:.*/, // don't bundle built-in Node.js modules (use protocol imports!)
      ],
    },
    target: 'esnext', // transpile as little as possible
  },
  plugins: [dts()], // emit TS declaration files
})

You will also need a tsconfig.json specifying root files and compiler options. If you don't have one yet, you can generate one with the appropriate create-vite TypeScript template, e.g. vanilla-ts.

Há um bom tempo considero liberar o código-fonte do aplicativo, e seu descontinuamento foi o empurrão que faltava para a mudança. Tal abertura oferece à comunidade acesso ao conhecimento acumulado durante anos de desenvolvimento.

O código-fonte do Carteiro está disponível no GitHub.

Em abril de 2012, o Carteiro era lançado.

Desde então, o aplicativo (que era pago) se tornou gratuito, o número de usuários cresceu expressivamente, foi recomandado por diversas publicações de tecnologia, destacado na Play Store entre produções brasileiras, e até mesmo participou do pacote de aplicativos nacionais da LG.

Uma constante ameaça durante todos esses anos, porém, foram os próprios Correios. Como não tenho empresa e, portanto, contrato com a ECT, não tenho acesso à API oficial de rastreamento. Isso me forçou a extrair dados de páginas web, migrar para APIs não oficiais, e/ou usar credenciais de teste para validar requisições. A completa falta de comunicação resultou muitas vezes na interrupção do serviço, que felizmente sempre consegui contornar. Bem, até agora.

Os Correios fecharam a última porta na semana passada, quando puxaram da tomada a API de seu finado aplicativo móvel. Dessa forma, não há mais como o Carteiro buscar informações sobre o andamento das entregas, pelo menos não sem investir uma quantidade de tempo e recursos que não tenho à disposição no momento.

Apesar do sucesso, o Carteiro sempre foi um hobby, sem qualquer retorno financeiro significativo. Resisti a colocar propagandas, porque meu principal objetivo era criar um produto agradável, focado na experiência do usuário e respeitando sua privacidade. Mas como a maioria dos meus hobbies, eventualmente me cansei dele. Não apenas isso, hoje tenho diferentes prioridades, e pouca motivação para contribuir conteúdo aos jardins murados de gigantes da tecnologia.

Chegou a hora do Carteiro pendurar o boné e ter um merecido descanso. A todos os destinatários e remetentes que confiaram no meu trabalho, meu sincero muito obrigado. E quem sabe, abrindo o código-fonte do projeto e com apoio da comunidade, ele não faça uma nova tentativa de entrega?

Um abraço!

Rafael Bardini

Atualização 21/05/2023: o código-fonte do Carteiro foi liberado.

• Inclusão de leitor de código de barras próprio
• Atualização da lista de status

A nova versão do Carteiro está disponível gratuitamente no Google Play.

• Melhorias de design—novos esquemas de cores e interface mais limpa ✨
• Uso do seletor de arquivos ao criar/restaurar backups
• Atualização da URL da página do SRO
• Atualização das listas de status e serviços postais
• Correção de bugs
• Remoção do suporte a Android 7.1.1 ou inferior

O novo esquema de cores claro apresenta tons pastéis, enquanto a maioria dos elementos decorativos foram removidos:

A nova versão do Carteiro está disponível gratuitamente no Google Play.

• Melhorias de design—maior contraste e tema escuro mais escuro 🌒
• Adição de opção padrão do sistema à lista de temas
• Cópia do código de rastreamento ao pressionar e segurar texto
• Definida largura máxima da tela de adição de objeto
• Exibição da data do último backup automático realizado
• Correção de bugs durante adição e sincronização de objetos
• Remoção do suporte a Android 5.1 ou inferior

O redesenhado tema escuro traz um melhor contraste entre os elementos, facilitando a leitura enquanto consome menos energia:

A nova versão do Carteiro já pode ser instalada gratuitamente pelo Google Play.

Luckily, additional options can be passed to Istanbul reporters. I couldn't find documentation for the text reporter, so I digged into its code and found the skipFull option:

 {
   "coverageReporters": [
-    "text"
+    ["text", { "skipFull": true }]
   ]
 }

This hides all rows with full coverage, letting you focus on what matters most: partially or fully–uncovered files.

I also recommend jest-silent-reporter for an even quieter output (especially in CI builds) and jest-it-up to automatically bump up global Jest thresholds.

You decide to write a function to strip all these null values from the response, so that they conform to your types:

function stripNullableProperties(obj) {
  // Return a new object without null properties
}

How can you strongly type such helper without duplicating your input and output types? You could try:

function stripNullableProperties<T extends {}>(obj: T): T

But it won't work in strict null checking mode, since obj might have null values that are not assignable to the non-nullable optional properties in T:

type A = {
  x: number
  y?: number
}

stripNullableProperties<A>({
  x: 1,
  y: null, // Error: Type 'null' is not assignable to type 'number | undefined'.
})

What you really need is something like:

function stripNullableProperties<T extends {}>(obj: NullableOptional<T>): T

The NullableOptional<T> type

The NullableOptional<T> type constructs a type with all optional properties of T set to nullable:

type A = {
  x: number
  y?: number
}

type B = NullableOptional<A>
// {
//   x: number
//   y?: number | null
// }

You won't find NullableOptional in the TypeScript documentation, and that's because it's a custom type. It actually looks like this:

type RequiredKeys<T> = {
  [K in keyof T]-?: {} extends { [P in K]: T[K] } ? never : K
}[keyof T]

type OptionalKeys<T> = {
  [K in keyof T]-?: {} extends { [P in K]: T[K] } ? K : never
}[keyof T]

type PickRequired<T> = Pick<T, RequiredKeys<T>>

type PickOptional<T> = Pick<T, OptionalKeys<T>>

type Nullable<T> = { [P in keyof T]: T[P] | null }

type NullableOptional<T> = PickRequired<T> & Nullable<PickOptional<T>>

In short:

1. pick the required properties from T;
2. pick the optional properties from T and make them nullable;
3. intersect (1) with (2).

With this, you can remove all nullable properties from an object whose interface should only have non-nullable optional properties, while still ensuring type safety:

type A = {
  x: number
  y?: number
}

stripNullableProperties<A>({
  x: 1,
  y: null,
})
// {
//   x: 1,
// }: A

You could always do a type assertion and avoid all this trouble, but ensuring type safety—even in seemingly unharmful cases like this one—pays off in the long run.

While implementing new features and refactoring parts of the frontend application, we frequently faced an issue: some GTM events would go missing, be duplicated, dispatch at the wrong time, or just lack important dimensions. This can heavily impact our ability to analyze the data, and thus demanded a lot of manual testing to ensure that everything was working as intended.

We already have end-to-end tests in place, doing a lot of user interactions throughout the website, that in turn push events to the data layer. What if we could extend these tests to also check if the information in the data layer is consistent? Since the data layer is basically an array of JavaScript objects, we can do a sort of snapshot testing, comparing the current values with what we expect them to be.

In this article, I will cover how we automated GTM data layer testing using our end-to-end test framework of choice, TestCafe. The same principles can be easily applied to other test frameworks though.

Retrieving the data layer

The data layer is assigned to a global dataLayer variable. To retrieve the data layer items in end-to-end tests, we must execute code in the browser's context. In TestCafe, this can be done with a ClientFunction:

import { ClientFunction } from 'testcafe'

const getDataLayer = ClientFunction(() => window.dataLayer)

However, if you try to run this function in your tests, you may face the following error:

ClientFunction cannot return DOM elements. Use Selector functions for this purpose.

This happens due to some events like gtm.click containing references to DOM nodes, which cannot be serialized. One way to fix this is to traverse over all items and remove any such references before returning the data. I will leave this as an exercise, mainly because the problem went away once we started filtering out default GTM events, as I will explain in the next section.

Filtering out default GTM events

One thing I noticed after printing the data layer a couple of times was that default GTM events (e.g., gtm.load, gtm.click) would fire at different points in time, thus their order would not be the same and our tests would often fail. To avoid this issue, I decided to simply filter out these default events, since they are not very relevant to us—we care more about the custom events we fire ourselves.

All default GTM events start with gtm, so we can just ignore them with a filter on the event name:

const getDataLayer = ClientFunction(() =>
  window.dataLayer.filter(({ event }) => !event.startsWith('gtm')),
)

Comparing the data layer

Now that we have the data layer in hand, we can make assertions on it. Write your reference data layer snapshot and do a deep equality check against it²:

import { t } from 'testcafe'

const dataLayerSnapshot = [
  { event: 'productClick' },
  { event: 'addToCart' },
  { event: 'removeFromCart' },
  { event: 'promotionClick' },
  { event: 'checkout' },
  { event: 'checkoutOption' },
]

await t.expect(getDataLayer()).eql(dataLayerSnapshot)

If the data layer does not match the snapshot, the test will fail:

AssertionError: expected [ Array(5) ] to deeply equal [ Array(6) ]

Then it is a matter of fixing the code if it is a regression issue, or (manually) updating the snapshot.

Bonus: improving test failure output

You probably noticed that the error message is not very helpful—it does not tell you exactly what the difference is between the expected and the received values.

We can work around this by doing a string comparison instead, stringifying both the data layer and the snapshot before the assertion:

const getDataLayer = ClientFunction(() =>
  JSON.stringify(
    window.dataLayer.filter(({ event }) => !event.startsWith('gtm')),
  ),
)

const dataLayerSnapshot = JSON.stringify([
  { event: 'productClick' },
  { event: 'addToCart' },
  { event: 'removeFromCart' },
  { event: 'promotionClick' },
  { event: 'checkout' },
  { event: 'checkoutOption' },
])

Not pretty, but it does the job—although it is still a bit difficult to spot what the actual problem is:

AssertionError: expected

'[{"event":"productClick"},{"event":"addToCart"},{"event":"promotionClick"},{"event":"checkout"},{"event":"checkoutOption"}]'
   to deeply equal

'[{"event":"productClick"},{"event":"addToCart"},{"event":"removeFromCart"},{"event":"promotionClick"},{"event":"checkout"},{"event":"checkoutOption"}]'

In a follow-up post I will explain how we managed to improve this even further by using the expect module inside TestCafe for a more Jest-like assertion output.

Conclusion

Manually testing the data layer after each frontend change is a very time consuming process. Inspection tools like dataslayer can help, but they are no match for proper automation. By leveraging the power of end-to-end tests, we can save valuable time from developers and data analysts, while being more confident that changes to the codebase will not negatively impact sales and performance tracking.

• Opção de desfazer ao arquivar ou excluir objetos
• Correção da seleção do tema não sendo aplicada
• Melhorias de design, interação e desempenho

A interface está mais harmoniosa, com todos os elementos alinhados à grade, e a transição entre a lista de objetos e o histórico seguindo melhor as diretrizes do Material Design.

Além disso, a maioria das janelas de confirmação foram substituídas por opções de desfazer, minimizando interrupções durante o uso.

Instale já o novo do Carteiro no seu Android e aproveite todas as novidades!

After digging into the Netlify REST API, I managed to make a badge that fetches all deploys for my site and extracts the status of the last deploy:

[![Deploy status](https://img.shields.io/badge/dynamic/json.svg?url=https://api.netlify.com/api/v1/sites/rbardini.com/deploys&label=deploy&query=$[0].state&colorB=blue)](https://app.netlify.com/sites/rbardini/deploys)

Which looks like this:

One shortcoming is that you cannot set a different color depending on the status, that's why I'm using a "neutral" blue background here. Also, I assume deploy logs must be public for the link (and possibly the badge itself) to work.

• Melhorias no processo de sincronização automática
• Opção de sincronizar objetos ao iniciar
• Opção de falar com os Correios no menu de navegação
• Adição de nova categoria "em trânsito"
• Opção de alterar a categoria exibida ao iniciar
• Exibição da última sincronização no menu de navegação
• Opção de marcar todos os objetos durante seleção
• Adição da bandeira de Hong Kong
• Correção dos botões de adição de objeto em telas menores
• Correção do tema escuro após abrir objeto no SRO

O foco dessa versão é aprimorar as sincronizações em segundo plano, reagendando-as sempre que necessário, como nas ocasiões em que o sistema termina o processo para liberar memória ou economizar bateria. Além disso, agora a lista de objetos é atualizada automaticamente ao abrir o aplicativo, e é possível checar o momento da última sincronização no cabeçalho do menu de navegação.

Confira essas e outras as novidades instalando a nova versão do Carteiro no seu Android!

• Muitas melhorias de interface, novo ícone e tema escuro!
• Utilização do web service oficial dos Correios
• Opção de desabilitar teclado adaptativo
• Adição de múltiplos objetos facilitada
• Chance de pular a busca inicial por dados ao adicionar objeto
• Seleção de objetos via ícone de status na lista de rastreamento
• Alerta se serviço dos Correios está fora do ar durante sincronização
• Lista de serviços postais atualizada
• Removido suporte a Android 4.4 ou inferior

A maior novidade, sem dúvida alguma, é o novo tema escuro, muito pedido pelos usuários e que pode ser ativado na categoria Aparência da tela de configurações do aplicativo. Mas uma outra melhoria que será bastante útil, principalmente para aqueles que adicionam vários objetos sequencialmente, como lojistas e comerciantes, é o novo fluxo de adição de objetos. Agora, é possível pular a busca inicial por dados do objeto, lembrar de não pedir confirmação por objetos não encontrados e adicionar um novo objeto em seguida, com apenas um toque:

Instale agora o novo Carteiro no seu Android! Lembrando que o Carteiro passa a suportar apenas Android 5.0 ou superior a partir dessa versão, caso a atualização não seja oferecida ao seu aparelho. E se quiser ficar por dentro das últimas novidades, não deixe de participar do programa de testes :)

Obrigado pela compreensão e apoio,

Rafael Bardini

Atualização 17/06/2016: o WebSRO está de volta, e o Carteiro também :)

De Botton is one of the minds (and sometimes also the voice) behind The School of Life channel, which I highly recommend you to subscribe to.

∞ Permalink

"Death by hyperthermia" is the official designation. When it happens to young children, the facts are often the same: An otherwise loving and attentive parent one day gets busy, or distracted, or upset, or confused by a change in his or her daily routine, and just... forgets a child is in the car.

This is one of the most disturbing, eye-opening articles I've ever read, not because those parents are monsters, but because it could potentially happen to any of us.

Quoting David Diamond, a professor of molecular physiology at the University of South Florida:

"The quality of prior parental care seems to be irrelevant," he said. "The important factors that keep showing up involve a combination of stress, emotion, lack of sleep and change in routine, where the basal ganglia is trying to do what it’s supposed to do, and the conscious mind is too weakened to resist. What happens is that the memory circuits in a vulnerable hippocampus literally get overwritten, like with a computer program. Unless the memory circuit is rebooted -- such as if the child cries, or, you know, if the wife mentions the child in the back -- it can entirely disappear."

I think these cases also say a lot about how innocent people, like rape victims, are sometimes blamed by others in order for them to cope with the harsh reality that the world is not inherently fair:

Humans, Hickling said, have a fundamental need to create and maintain a narrative for their lives in which the universe is not implacable and heartless, that terrible things do not happen at random, and that catastrophe can be avoided if you are vigilant and responsible.

In hyperthermia cases, he believes, the parents are demonized for much the same reasons. “We are vulnerable, but we don’t want to be reminded of that. We want to believe that the world is understandable and controllable and unthreatening, that if we follow the rules, we’ll be okay. So, when this kind of thing happens to other people, we need to put them in a different category from us. We don’t want to resemble them, and the fact that we might is too terrifying to deal with. So, they have to be monsters.”

Jeff Atwood wrote a great piece on this behavior in relation to internet harassment, so please check it out.

∞ Permalink

It's now being served by GitHub Pages too, with the code available here. I'll write some follow-up posts soon detailing the plugins and scripts I've used to build and deploy the site.

Stay tuned.

• Adicionada opção de sincronização apenas via Wi-Fi
• Menu de navegação redesenhado
• Suporte a permissões individuais e backup automático de dados no Android 6.0+
• Reorganização das configurações do aplicativo
• Lista de serviços postais atualizada
• Correção de bugs e melhora do desempenho

Com essa atualização, o menu de navegação passa a contar com ícones, facilitando a identificação de cada categoria, bem como um cabeçalho estilo Material Design:

Já a opção de sincronização apenas via Wi-Fi permite limitar o consumo do plano de dados móvel. Essa opção pode ser encontrada na seção Sincronização nas configurações do aplicativo, e requer uma nova permissão para acesso ao estado da rede.

Aproveite todas a novidades instalando já o Carteiro no seu Android!

Quando perguntamos a nossa amiga casada quando ela vai finalmente ter filhos ou filhas, a pergunta nos parece inócua e amigável. Afinal, só estamos perguntando porque temos intimidade, certo?

Entretanto, para a pessoa que está do outro lado, o comentário é opressivo. Porque não é a primeira, nem a vigésima, nem a centésima vez que é feito.

Como essa pessoa pode se sentir acolhida, feliz, aceita entre suas amigas e familiares se praticamente todo dia alguma delas a interpela sobre uma das escolhas mais importantes de sua vida?

A mensagem passada por essa constante enxurrada de comentários, uma mensagem ao mesmo tempo violenta e invasiva, é que a sua escolha de vida, que deveria ser íntima e indevassável, causa enorme desconforto às suas pessoas mais próximas. Se não, por que tanta insistência? Se não, por que tanta intrusão?

Em situações como essa, é ainda mais apropriado seguir o conselho supostamente dado pelo guru indiano Sathya Sai Baba (tradução minha):

Antes de falar, pense: É necessário? É verdadeiro? É gentil? Machucará alguém? Acrescentará algo ao silêncio?

Pense, sempre.

∞ Permalink