Olá, obrigado pelo feedback.

Como eu estou desenvolvendo essa biblioteca há umas duas semanas, com certeza ainda há muito o que se melhorar.

Em relação ao armazenamento do estado, o window.REACT_TRIGGER_STATE funciona para inicializá-lo.

Isto é, quando um componente é montado, verifica-se, no window.REACT_TRIGGER_STATE, se há tal variável, se não existir, ele a cria, de outra forma, utiliza-se o valor disponível.

Depois disso, quando o state é alterado, o window.REACT_TRIGGER_STATE é atualizado.

Mas o que compartilha, de fato, que X estado fora alterado é um CustomEvent.

Por isso, cada estado tem um CustomEvent associado a ele que monitora as atualizações.

Espero que tenha conseguido expor a minha ideia e do porquê de eu ter feito dessa forma.

Infelizmente, não consegui pensar numa forma de armazenar o state sem utilizar o window e o CustomEvent ao mesmo tempo que não seja necessário encapsular toda a aplicação.

Mas, se você tiver alguma sugestão, eu ficaria muito feliz em te ouvir.

Obrigado pela crítica, ela é muito importante para o meu crescimento.

Oiii então, aquela crítica realmente me ajudou.

Hoje eu refatorei o código utilizando um Hook do React: useSyncExternalStore.

Esse hook permite criar um subscriber e uma função getSnapshot.

Em suma, a primeira vai iniciar o state.

Já a segunda pega as alterações que ele vem a sofrer.

Então, eu consigo emitir que X alteração aconteceu e todos os states que o contém conseguem pegar as modificações.

O melhor de tudo: não precisa usar o window e tampouco adicionar um eventListener para cada novo state.

O hook do React faz isso por nós!

Por causa disso, o usuário final, não tem como saber a informação crua do state ou alterá-la.

E isso também reduziu o size de 24kb para apenas 11kb!!

vlw manito!

Brigadão! 😼

obrigado!! ah e feliz pascoa hehe.

alias, eu já dei uma terceira melhorada nela, agora vc consegue setar o state como um localStorage e ele altera globalmente :)

import { stateStorage, useTriggerState } from "react-trigger-state";

// em alguma função
const value = stateStorage.set("my_first_state_storage", "testeee");

// esse cara pega as alterações q o de cima fzr (sem estar no msm componente :D)
const [state, setState] = useTriggerState({
  name: "my_first_state_storage",
});

daí se consegue fzr umas loucuras q nem essas:

import { stateStorage, useTriggerState } from "react-trigger-state";

// em alguma função
const value = stateStorage.set("my_first_state_storage", "testeee");
const value2 = stateStorage.set("outro_state", "testeee 1");
const value3 = stateStorage.set("outro_state2", "testeee 2");

sem precisar importar um milhao de states kk

Oi @cay, obrigado pelo feedback!

Sobre o título, eu criei esse número para chamar a atenção, mas não é um dado real. Todavia, em relação a praticidade, eu percebo que consigo poupar tempo e linhas de código com ela.

E sim, não tenho como objetivo principal substituir o Redux ou o ContextAPI, mas sim, complementá-los.

Por exemplo, eu uso o Redux para gerenciar o estado de autenticação do usuário, e o React Trigger State para gerenciar o estado de um componente específico.

Pra motivos de curiosidade, um estagiário meu que deu essa ideia, tipo, se é possível pegar o onClick de um botão, por que não pegar o useState de um componente?

E eu fiquei pensando nisso, e pensei, por que não? E aí eu fiz essa lib.

Por causa disso, já consegui utilizar numa outra lib de design que eu tô fazendo ainda (gt-design hehehe) que tem o objetivo de ser o melhor design system de react (hueheu), daí o usuário nem precisa se preocurar em ficar criando um monte de estado, só precisa criar um nome para o componente da lib e pronto, ele já tem pelo menos 3 estados compartilhados com informações da página.

Ahhh, e muitíssimo obrigado pela estrelinha! 🤗

[edit]

Mas tava pensando agora... talvez, com algumas melhorias, daria pra usar o React Trigger State como um substituto do Redux, mas, enfim, isso é pra um futuro bem distante hehehe.

Sim, faz. Porém exige criar uma estrutura pra isso (no caso de Redux, tem store, actions, etc.) Tem também a Context API (onde é necessário criar contexts e providers, etc.), que na minha opinião é mais fácil de usar, e tem o mesmo objetivo, gerenciamento de estado.

No caso a biblioteca que o @geavila criou, também tem o mesmo objetivo, que é evitar prop drilling e facilitar o compartilhamento de estados entre componentes, só que de uma forma diferente, e simples de usar.

Oi! @RodrigoSalomonDev, então, como o @cay escreveu, o objetivo do React Trigger State, é complementar o Redux.

Então, enquanto o Redux é uma biblioteca que permite que você gerencie o estado da sua aplicação de forma global.

O React Trigger State, permite que você compartilhe o estado entre componentes sem ter que passar por props.

Um exemplo seria, um componente que cria um estado para um input, e outro componente que consome esse estado.

Você não precisaria criar um avô para compartilhá-lo, você poderia usar o React Trigger State.

Olhe nesse exemplo (usando redux):

Já aqui, usando o React Trigger State:

Consegue ver a diferença?

Com o React Trigger State, você poupa tempo neste processo de compartilhamento de estado, sobretudo, com informações que não precisam ser compartilhadas com toda a aplicação.

Mas... talvez... no futuro ... eu melhore o React Trigger State para que ele possa ser usado como um substituto do Redux hehehe.

Espero que tenha conseguido tirar a tua dúvida!