Unachievable dreams?
I am sure sometimes you lean back and wonder how we got to the status quo regarding the stacks we use. I mean, does...
For further actions, you may consider blocking this person and/or reporting abuse
Hooks are great, but for me they don't come close to replacing redux. Redux is designed to make it easier to manage state. Some people don't like to manage state this way, and so hooks are great for them - but for those of us that do like redux as a state container, hooks aren't that.
Well see, then it failed. I tutor junior devs and stores are one of the topics most discussed.
Sorry, let me rephrase, I was wrong to say:
It is in fact designed to make it simpler. Handling state gets very complex very quickly. This problem scales with the size of an application. Redux lets us control state, to minimise it, and to manage it within a subset of the language. This ultimately makes it easier to reason about.
Junior devs may not pickup Redux straight away but I'm not entirely sure they should. Making something easy to understand in order to appeal to the lowest common denominator in terms on language experience doesn't really seem like a long term plan for building reliable applications.
On a personal level I actually think that redux is easy enough to learn, the problems are that people think it's for something it isn't (injecting props arbitrarily throughout a component tree) and that the concepts (immutable state, functional patterns) are so alien to people that they have a hard time moving past them to understanding the overriding concepts.
I agree with that. But that doesn't mean I can't derive the conclusion that if something has a huge learning curve and maintenance cost it might not be an ideal solution.
This certainly does not mean that I want to advocate for a passing down props/callbacks a gazillion levels and bubbling events up to grandparent's parents.
What I am saying is: I remember the feeling of being surprised that there isn't a better solution. And I am not alone with this. My approach for VueJS is a concept known to React devs from recoil
I didn't actually mean to disagree or pick holes in your original post, sorry if it came across that way. I just see a lot of people complaining about using Redux because it's a heavy-weight way to inject props, which seems slightly unfair to me.
I'm all for anyone advocating any approach that they've at least slightly thought through, so good luck to you with this approach.
Oh, don't worry, I didn't take it that way.
well then.., what thoughts do U have about usability 4 'state' within stateLESS env like API?
I'm not sure I understand the question - you're asking how state can be used in a stateless environment? I would imagine very little?
Redux does have a state && I'm not sure U do understand, do U?
I think that you guys have the issue that one is talking about the backend state (and then referring to stateless sessionless), and the other about the client side state.
There is no more backend && frontend 4 JS when single-4-all Node'd come 2 place || what do U MEAN by that?
D.R.Y fool anymore. but raise 2 full up D.I.Y stack.
Can you rephrase that? I read this comment multiple times without getting closer to its meaning.
{D.R.Y: en.wikipedia.org/wiki/Don%27t_repe...} fool anymore. but raise {2: to} {full up: en.wiktionary.org/wiki/full_up} {D.I.Y: en.wikipedia.org/wiki/Do_it_yourself} stack
Lol. Let me rephrase then: the acronyms in your comment aren't the issue: I don't know what you are trying to say with your comment.
Well, if acronyms is OK, then let me make a single friendly farewel K.I.S.S. As far as PHP @ backend is just a Preprocessor 4…, with advance of Node right time'd come 2 teach JS 2 do $IT @ backend but up 2 frontend
I give you that: I don't know if I am facing a language barrier, bot or troll
this kind of talk is not of my interests and moreover does not of my business. therefore this was my last comment for you. good luck.
K. Sorry, just really don't know what you are trying to input.