Feature request: add previous global state to addCallback parameters about reactn HOT 10 CLOSED

I solved it.

Actually the addCallback helper function has an undocumented 2nd and a 3rd parameters, which are - respectively - the dispatcherMap and the stateChange.

With the stateChange parameter I could very easily achieve what I was after.

I am more and more amazed by the elegance of this library.

@CharlesStover if you want, I can submit a pull request with the documentation updated.

from reactn.

@monteiz Would you be able to unblock yourself with something like this?

let previousState = {};
addCallback((newState, _, stateChange) => {
  // Check state difference here.
  for (const [changedKey, newValue] of Object.entries(stateChange)) {
    console.log(`${changedKey}: ${previousState[changedKey]} => ${newValue}`);
  }

  // Update previous state for future comparisons.
  previousState = newState;
});

from reactn.

Pull requests are always welcome.

If there's ever another upgrade to this package, it will most likely be a 3.x release, making current documentation moot. Up to you if you want to bother with docs. There is no ETA on a 3.x release, because it would require TypeScript 4.x, which currently has low adoption anyway.

I'm glad you solved your issue. :) Thanks for the support.

from reactn.

Created, it was a pleasure :)

About new upgrades, I would love to see reactn 3.x brought to life. If I may ask, why do you say that it would require TypeScript 4.x?

from reactn.

One feature I'd expect it to have is nested properties, so something like useGlobalState('nested', 'key', 'here') to grab { nested: { key: { here: 'VALUE' } } }. This requires TypeScript 4+ to determine what the type of nested.key.here is.

I'm not completely sold on if it's worth the effort yet. I've had TypeScript Playground demos that didn't match the live version in terms of capabilities, so I'd be afraid of configuration differences (e.g. create-react-app) between my test environment and users' production environments causing issues. There is no ETA due to the ambiguous time investment it would take to bring that to life.

from reactn.

But that is something you can easily code in the useGlobalState function itself. You do not need to add a complexity layer, which severely limits the help you can get from the community. Plus, reactn codebase is quite light (and that is because you found an amazing approach to solve the problem), so I do not see the benefit to use TypeScript at all. You are just cutting out collaborators ;)

My opinion? I am sceptic about this whole TypeScript trend, my sensation is that it will vanish soon, and for a reason.

Having coded a lot in Java and C++, I was seriously tempted to use it because of the strong typing, which I miss in vanilla JavaScript. But I decided that it is a no go for me because at the end it adds complexity to the projects setup, and push you away from the international standard. I work with babel + webpack, so I can use whatever feature in the new JavaScript versions, and babel transpile the code to the most adopted JavaScript version.

I am confident that the next versions of standard JavaScript will be supporting strong typing as well as all the good TypeScript features, which babel will transparently transpile for me. And my project will stay within the standard, meaning that everybody can work on it and all the tools out there are supported.

To me, TypeScript merely represents a "wrong turn"...

from reactn.

I feel like there is some confusion here about the "need" for TypeScript. TypeScript offers two things to the consumer: (1) IntelliSense to tell you if your code is valid as you type it, and (2) type-checking to tell you if your code is valid before you build it. Neither of these two benefits are requirements for building an application. TypeScript transpiles down to vanilla JavaScript. A non-TypeScript app, written in JavaScript, can still use the output of a TypeScript library, because it too is also JavaScript. You simply lose the IntelliSense auto-complete and the build-time type-checking, but you do not need these things to have a functioning app. They are just nice to have.

What I mean to say when I say it will "require" TypeScript 4.x is that TypeScript 3.x projects will not be able to integrate with IntelliSense or build-time type-checking. They will otherwise function fine at runtime.

from reactn.

@CharlesStover Thanks for clarifying that.

I think we agree on the "nice to have" features of TypeScript. I hope you'll agree with me that the price of those "nice to have" would be a severe reduction of the support you can get from the community, which is a fundamental factor for the success of any opensource project.

And I want to emphasise that If I say all this, it is because I want you and ReactN x.x to have the recognition it deserves!

from reactn.

Hi @CharlesStover, I think we should reopen this issue.

I have a case where I need to know if a particular property of the global property has been changed.

With the stateChange parameter of the addCallback function, one can see what property of the global object has been changed, but not what has been changed in that property.

I think a good way to tackle this is to add a fourth parameter to the addCallback function, defined as the previous global object. This way one can make the necessary comparisons, if needed.

That would also open the way to a "global history", which one could use to easily implement a global object time travel (undo, back, forward and so on).

from reactn.

@CharlesStover that will work great, simple and effective, thanks!

from reactn.