Hookstate 4.0.0 has been released!

[avkonst]

After almost a year of development and battle testing by a number of production-running commercial applications, Hookstate 4 has been released!

Hookstate 4 gained some more unique features, which step up a game in the state management libraries domain. Have a look what is new and how to migrate to the version 4.

And share your feedback and thoughts below in comments.

[cristi-shoreline]

@avkonst Congrats on releasing the 4.0.0, that's a huge step forward for Hookstate. 🎉

I'm having a few issues with 4.0.0 though, after upgrading from 4.0.0-rc21 (fortunately, it's a POC, but we're eager to start using it on production environments).

So, I'm a bit surprised that the values returned from states are now wrapped in ImmutableObject and ImmutableArray in 4.0.0 while in the release candidate they were plain objects. Was this intended?

More than that, if I'm getting the value from a scoped state, like useHookstate(state).value, it's wrapping the immutable objects/arrays once again.

Maybe we're doing something wrong here. 🤔

[avkonst]

Double wrap of immutable is a bad bug. I will address it. Immutable declaration was intended but not the double wrap. We will see what the community says. I have received some feedback that immutable wraps are doing more bad than good. But the returned state.value is certainly is readonly thing. It throws if modified in runtime.

…

On Fri, 23 Dec 2022, 06:55 Cristi Socea, ***@***.***> wrote: @avkonst <https://github.com/avkonst> Congrats on releasing the 4.0.0, that's a huge step forwards for Hookstate. 🎉 I'm having a few issues with 4.0.0 though, after upgrading from 4.0.0-rc21 *(fortunately, it's a POC, but we're eager to start using it on production environments)* . I'm a bit surprised that the values returned from states are now wrapped in ImmutableObject and ImmutableArray. Was this intended? More than that, if I'm getting the value from a scoped state, like useHookstate(state).value, it's wrapping the immutable objects/arrays once again. Maybe we're doing something wrong here. 🤔 — Reply to this email directly, view it on GitHub <#365 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JSVML36VVMYVO5A6HYDLWOSIYRANCNFSM6AAAAAATC6KP6U> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zroug]

I prefer the new immutable return type. I think using the type of the wrapped value directly isn't sound, and it tripped me off before. However, I do think the return type can be a bit more granular. When using get with noproxy or stealth the returned value isn't wrapped, and I think the type should show that using an overload. Right now, I have to cast the return type when passing class instances to functions.

Regarding the double wrap bug: I encountered it too. Edit: Actually I'm not sure, my issue might be caused by something else.

[3rma1]

how do you update ImmutableObject?

[avkonst]

You update it via a state.set() . https://hookstate.js.org/docs/nested-state#setting-new-state-value

[avkonst]

Double wrap by Immutable is fixed in core 4.0.1

[wulfri-dng]

What did you mean by the double wrap here? Still, in v4.0.1, we are getting returned state.value wrapped in ImmutableObject and ImmutableArray as @cristi-shoreline mentioned above. It's difficult to handle and manage returned values that are wrapped as Immutable and our team is looking for a solution to get plain objects as it is.

This doesn't give any functionality issues but it's difficult to handle data types all across the project. We already use hookstate through a custom state management hook and we do not intend to import Immutable data type all across the project.

Maybe we are doing something wrong here. Can you guide me to return plain objects as it is or do you intend to remove Immutable data types in a future release?

[avkonst]

Double wrap was a bug. Was fixed. Value is returned as Immutable because you are not supposed to modify it.

"This doesn't give any functionality issues but it's difficult to handle data types all across the project. We already use hookstate through a custom state management hook and we do not intend to import Immutable data type all across the project." - this is a good feedback

Maybe we are doing something wrong here. Can you guide me to return plain objects as it is or do you intend to remove Immutable data types in a future release?

You can use state.get(no proxy option) but it has downsides. State value may get mutated by your application uncontrollably.

[avkonst]

"do you intend to remove Immutable data types in a future release?"
that is a good question. Since it was introduced, I have received conflicting feedback - some people liked it very much and it uncovered a few bugs for them. Some people, like you, faced some difficulties with it. I totally understand the issue around Immutable polluting the entire project, I have experienced it myself and question if extra type safety was worth it. I appreciate if people provide some feedback on this.