In this article series, we embark on a journey through the realm of custom React hooks, discovering their immense potential for elevating your deve...
For further actions, you may consider blocking this person and/or reporting abuse
Shouldn't all of these functions be wrapped in
useCallback(..., [setArray])? Having consistent function references outside seems preferable.Also, I'd advise against using
setas a function name - collision with likely keywords.Absolutely) Wrapping these functions with
useCallbackwould help maintain consistent function references and optimize performance.Hey, nice article. I do understand what you're trying to do with this, but don't you think this is too much wrapping for something that should already be pretty straight-forward?
The only reason for adding this extra wrapping in my mind would be if you do A LOT of array manipulation in your project. And if you do, all those set states compound, and might cause more rendering issues, and then you have to wrap things in
useCallbackto optimize, etc.Also, adding any library to your codebase has a maintenance price. Personally, I think it's easier to just let developers mess with an ordinary array and then set state manually, then to introduce another library to the project and increase complexity.
Thanks for sharing your perspective, Dušan. Your points about the trade-offs between simplifying array manipulation and potential rendering issues due to increased state updates are valid considerations. It's important to weigh the benefits of cleaner code against the potential complexities introduced by additional libraries. Different projects may require different approaches based on their specific needs.
I understand the desire to create a hook for immutably modifying arrays with terser syntax, but IMO this implementation adds an additional layer of overhead any developer working with the code needs to understand
A more idiomatic approach could be to use a proxy object representing the array, such that any native JavaScript mutative array method (push, pop, splice, etc.) can be freely used to update the copy of the array without inadvertently causing side-effects.
One other thing that isn’t super clear to the consumer of this hook is what operations are “allowed” to be called on the returned
array? E.g. is it bad to do something likearray.splice()?Regarding the clarity of allowed operations, you bring up a valid concern. It might be beneficial to provide clearer documentation or comments indicating which operations are safe to use on the returned array. This would help developers understand the limitations and prevent unintended side effects.
Thanks again for your insights and constructive feedback!
I’m glad I follow you .....
If you have any questions or suggestions, feel free to share them with me. Happy coding!
it's pretty simple!!
Indeed, the "useArray" custom hook simplifies array management in React applications.
What's the point of this? Does it help with actual development? Encapsulated components should be triggered based on the actual scenario, not encapsulated for encapsulation's sake...