React and Redux are a joke right?
81–90 of 119 posts
Re: React and Redux are a joke right?
#82Re: React and Redux are a joke right?
#83Earlier quoted context omitted.
The whole "separate HTML, JS & CSS" idea I don't believe is something that should go unchallenged. It was "best practice" back in the days for years and mostly just because it was best practice, but also because at that time it made juust that much more sense where web applications were more primitive and closer to a semantic HTML "document" with some interactivity sprinkled on top (remember when AJAX was bleeding ed…
React+Redux is still very focused on separation of concerns, but now it's all in the JavaScript side: "where is the JS for this JS?" is the question now. Components, states, props, actions, reducers, stores, etc. React has just as many "separation of concerns" as ever.
A lot of those things are in a way a fundamental side effect of lenient languages and dynamism.
Having said I think it's definitely nowhere near as bad.
I use Typescript and modern JS and types and the modules/import system does a lot to prevent those things.
Because in general I don't have any globals lurking around so for example the styling of a component is imported at the top in the same file so it's always nearby. So the symbols and variables that you see on the screen are more obvious in terms of where they come from.
Redux also while not perfect if you have a reasonable amount of discipline it doesn't get as bad as the old-school stuff.
Re: React and Redux are a joke right?
#84i get a feeling author had no prior experience with js ui whatsoever.
Re: React and Redux are a joke right?
#85Earlier quoted context omitted.
"there are no immutable primitives" Many array prototype functions work in an immutable way like map and reduce
Updating an array element arr[3] = 'New content'; Updating an array element immutably arr = arr.map((element, index) => { if (index === 3) return 'New content'; return element; }); It's possible, sure, but it feels terrible. JavaScript objects want to be mutated - it's the most idiomatic way of interacting with them. Whether functional programming paradigm is good (I certainly feel it is) is beside the point - JS was…
(set arr 3 "New content")
(set-in
deeply-nested
[arbitraty path to the element]
"New content")
convenient updates of immutable datastructures are possible.Re: React and Redux are a joke right?
#86Author complains about "lots of code" needed for changing his data, but at the same time refuses to use modern ES6 features.Most of his code would come down to 2-3 lines when using destructuring and object/array rest operator.
For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data.
So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component).
I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation.
So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help.
I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.
Re: React and Redux are a joke right?
#87Everything after the "but" and all.
The whole point of Redux is to separate actions and state manipulation. An argument that, "well I want to manipulate variables feely," is not an argument. Just don't use Redux. End of story.
The pattern doesn't come from React. There are many patterns in React that are just Monads by a different name. Redux isn't much different.
Re: React and Redux are a joke right?
#88Could somebody outline how I can write an efficient rich text editor using the state management techniques of React and Redux? (Not that I want to try this, but I'm interested in how that would work).
Re: React and Redux are a joke right?
#89There are several things about React, Redux and React based tech stacks:
1. React requires knowledge of basics of functional programming
React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. Without this knowledge, a lot of things will be a struggle and won't make any sense. You'll mess up pretty bad. React requires the understanding of its principles which require the understanding of FP essentials.
2. React is not a framework and does only one thing well
It does only one thing well, turning your UI into a function of data. Yes, there is a virtual DOM but it's an implementation detail and not the purpose of React. If you think about it everything which is there is needed to make that UI=F(data) possible. However, it's enough for simple apps.
Immutability isn't always needed so it's optional. It's not built into JS, you'll have to use an additional library.
3. Building non-trivial apps requires a lot of knowledge and experience
Building non-trivial apps with React only is a pain. That's expected because the only thing it does is making a UI a function of data. It's not a framework with a complete set of tools and practices for building a whole SPA. That means you have to assemble your own tech stack for your particular task. This requires a lot of experience but lets you have the tools which are a better fit for your app.
Redux is just one of the available choices for solving the problem of complex app's architecture. It isolates state from React components. UI interaction with the outer world is behind actions. Data access is behind selectors. State mutations are centralized in reducers. This is very convenient, you always know where to look for something. Business logic part is very clear because of actions and reducers. Not messing everything up requires knowledge and discipline though.
The funny thing is React+Redux isn't a complete framework. For case, there are several solutions for writing asynchronous actions.
The main idea is React is ok to use by itself for simple things. You don't need to know much except FP essentials. Using more advanced React based tech stacks requires much more knowledge and experience.
If you don't know which of your problems React solves you don't need it.
If you don't know which of your problems immutability solves you don't need it.
If you don't know which of your problems Redux solves you don't need it.