11–20 of 119 posts
Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?
Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?
My problem with it is that there is so much abstraction that almost no prior knowledge from using other frameworks or libraries is useful. It seems like everything is magic.
Here is a chain of react tech things: React->Flux->Redux->Redux-Persist->PersistGate
The latter is talked about in documentation, i.e., "do it like PersistGate does", but I can't find PersistGate anywhere.
With so many react extensions and libraries all having their own helper functions to do everything it seems like we are no longer programming, but instead, we are tasked with stringing together configuration functions after searching for hours for the currently relevant documentation.
I think react does some pretty amazing things, but the learning curve is too steep because of fragmented documentation (mostly the community created how-tos are the problem here), confusing abstractions, and poor method naming (thinking about redux's `reducer` here).
Anyway, I, and several programmers at my company, share your sentiments; you are not alone. This will probably be my last greenfield react project.
Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library?
>If you get 3 people react will end up re-rendering 3 times because of the code above.
Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault?
>So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays.
I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a tree and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for.
>Why is the UI library dictating how we store and manipulate our data!!!
It does not do this, it's a virtual DOM/diffing library (!!!).
>Maybe someone needs to start the browser over.
This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least.
Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?
Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?
The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.
Because imperative code and persistent, immutable data do not play nicely together.
Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?
The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.
Stopped reading half-way through, as lots of incorrect stuff off the bat. > In the react world though you can’t mutate your data Sure you can. > If you get 3 people react will end up re-rendering 3 times because of the code above. Each call to `setState` triggers a re-render. Nope, calls to setState are batched.
I think sometimes you need an outsider view to call out that the emperor isn't wearing any clothes, and that's going to result in botched details. I don't think it impacts the overall point the author is trying to make. I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less p…
90% of websites have no need for Javascript. Of those that do 90% won't be needing any "take over the world" frameworks, just little sprinkles of Javascript or jQuery.
Not to mention most required uses of Javascript are interaction related. At least let me read the landing page without having me enable javascript instead of greeting me with a blank page.
If the author wishes to continue with js/react/redux then he needs to pick up a library like immutable.js to cut down that immutabiilty helper crap. However, there is a better way ... lein new figwheel my-app, clojurescript+reframe gives you all the benefits of redux with an order of magnitude less boilerplate (also hot reloading and immutability by default without no extra setup or ceremony)
Immutable.js is just another complication with another 60k size penalty with a few new negative drawbacks that he would need more complexity to solve. Author is already arguing against this approach.
Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers.
Add to that tree-shaking (removing unused code) and the long term size of your app is looking good.
I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoops to get a project setup, or pick the latest and greatest build tool (grunt->gulp->webpack->jspm)
Earlier quoted context omitted.
The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.
Immutability in js is awful hence the complexity, a library like immutable.js can make it better, but the language is just not built for it. Because imperative code and persistent, immutable data do not play nicely together.