Context in react is designed for sharing some global data between components located at different levels of the component tree. It allows to avoid ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a great, thorough explanation, thanks a lot! I also found context in Reason very confusing at first. Thanks also for explaining why you can't use the normal React component annotation as well, that feels like a really important point.
Another trick, that's slightly more involved, is putting dispatch in a separate context, all by itself. That way you avoid having to pass a tuple (which I think will make all components using the context re-render as it creates a new array -> new context value each render) and components that only dispatch stuff don't need to re-render when state changes.
I guess more or less the same thing could be achieved with useMemo as well. Anyway, this probably only matters in a few use cases, but I thought it was worth mentioning as I've struggled with issues related to that myself.
I look forward to reading more articles from you!
Thanks a lot for your comment!
You are totally right about memoization and having separate contexts for dispatch and actual value. It is a cool trick to avoid re-render of components that only need dispatch. Funny, I actually have those points as a comment in the source code, but I thought I would leave them out from the article 🙂
I think I will add them in the end, since it is important people are aware of them in case they encounter one of those "few cases". Thanks for mentioning this info! 👏
You didn't use the hook in the app after all that?!?!?
For other's who might want to actually use it, example, here
Great write up, @margaretkrutikova . Nice details and teaching. Since you dug into
makeProps, why do we have to call it with a unit arg? As ininstead of which fails
Thanks again and keep it coming. Peace to you.
Sorry, could you clarify what you mean by "you didn't use the hook in the app"? I did use it here.
That's actually a very good question. Usually you need to pass unit
()in the end if you have optional labeled arguments. If you don't enforce this, the compiler won't know whether you want to partially apply arguments to your function (=curried function, and maybe pass that optional argument later?) or you actually want to omit that argument and call the function right away.I assume, since all components can optionally receive
keyas prop, you have to explicitly pass that unit to make sure it is going to be called and not partially applied. You can see here in the docs thatreasoncomponent will generatemakePropslike this:So I think it will always have that optional argument
key. I hope this makes sense!Indeed you did. In your post you had it assigned to a function and looked for that in the code. You ended up using it directly in form onSubmit. github.com/MargaretKrutikova/pract...
Nice.
Optional key. Of course. I was wondering which of these props is optional. Tack, Madame. You are appreciated!
Great article. Just a little question. Are we actually initializing user two times? Once in root and once in the context?
Thank you for your feedback!
That's a great question, I haven't really thought about it myself. It appears that the value passed inside
contextis a default value that will only be used if there is no matchingProviderin the tree, just found it in the react docs. Could be useful for testing components in isolation.I guess in the Javascript world one could simply omit passing a value in the context (resulting in
undefined), here inReasonhowever we must pass a value of the correct type (context value). If it is important to not compute the initial value two times (due to some heavy things going on there), one could make itoptionand passNonein context andSome(computedValue)in the root.