Thank you for writing this, I'm enjoying reading those small chunks.
But in this post I was surprised: For simplicity and less future code changes I would suggest to not rename the destrctured matches function.
Also everybody knowing the API of StateX will recognize the method and know what the code means, without checking where this custom name comes from.
In a simple example like yours it's of course not such a big issue, but if this becomes a habit or the code lives (and grows) longer then expected, as we all know it does most of the time, keeping it simple helps.
Yes you are right. I'd never destructure it in my code personally but thought I'd mention it anyway as it might be easier for some beginners to just deal with the one important function than to use the state object and possibly be confused by all the other stuff that they'll see in their editor once they type state.
Thank you for your feedback :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for writing this, I'm enjoying reading those small chunks.
But in this post I was surprised: For simplicity and less future code changes I would suggest to not rename the destrctured
matches
function.Also everybody knowing the API of StateX will recognize the method and know what the code means, without checking where this custom name comes from.
In a simple example like yours it's of course not such a big issue, but if this becomes a habit or the code lives (and grows) longer then expected, as we all know it does most of the time, keeping it simple helps.
Thx again for and keep up the good writing!
Yes you are right. I'd never destructure it in my code personally but thought I'd mention it anyway as it might be easier for some beginners to just deal with the one important function than to use the
state
object and possibly be confused by all the other stuff that they'll see in their editor once they typestate.
Thank you for your feedback :)