4 ms·

> As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're think

> As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? As stated before I haven't done a big JS project for about a year now. In the last project I did we used redux in a create-react-app. At the time the best practice was creating presentational and container components[1]. The biggest boilerplate was: - Whenever we added a react component (presentational) we would need to create a container component to wrap it in, this would always result in ~20 or basically the same lines (in our project we did things pretty verbose, so we didn't have a HoC or whatever people use). - "immutable update logic", reducing deeply nested objects is a pain an error prone (using es6 spread or Object.assign), I've heard about some libraries that can help with this, but we didn't use anything at the time). > FWIW, we have a new package called `redux-starter-kit` I am most definitely going to use this for an upcoming project! [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

acemarke 8y ago
FWIW, I've always felt that having duplicate / parallel "container" and "component" folders/files just for the sake of separating them is completely overkill. Most components are only connected once - just do that in the same file and export the plain and connected versions separately. I wrote some thoughts on that here: https://gist.github.com/markerikson/ea312b5ee398627ffceb09f89904831f https://gist.github.com/markerikson/ea312b5ee398627ffceb09f8... Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd like to have the tutorials and examples switch from a "folder-by-type" approach to either a "feature folder" or even a "ducks" approach, and maybe even cut down on having separate action constant variables. There's valid reasons to do things in multiple files, but it's also not _necessary_, and I want to simplify things. Yes, I totally agree immutable update logic is a pain to write and write correctly, which is why Immer is awesome, and why the starter kit uses Immer internally. My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. Please let me know how well it works for you, and if you've got any other suggestions for what it should include!
- askmike 8y ago
  Ah yes Immer is the framework I read about a few months back but couldn't find anymore. Thanks for reminding me. > My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. It's only a win since we decided that "mutation is bad" and we had to do spread notation gymnastics in all our es-2025 code that we are compiling to es5 anyway. From an abstraction point of view this is how I feel consensus about state management changed over time in the frontend world (or the part/frameworks I was involved in): - 2010: jQuery will help you update the DOM anywhere (looking at IE6) - but you have to solve state yourself. A deeply nested object attached at `window` was considered best practice. - 2012: We need to manage state properly, here is a nice Backbone "model" class: pass it a schema and use getters/setters to update so you can glue state change events to your view logic. - 2014: Angular (first version) is great! Don't worry about managing your state yourself, just attach whatever you want to $scope and we will simply use dirty checking to check everything whenever something changes. - 2015: React uses a vdom which behaves similar: change whatever you want and keep rendering it and React will figure out what actually changed. And for your state we made this flux thing which you implement as a bunch of different data stores (in my mind similar to backbone models except they only go "one way"). - 2016 (redux): here is a single store that also flows one way. Oh yea you need to do everything functional and you can't mutate any objects anymore or things will break. These 20 lines of code show you how to change the property of object with another property called id with value "x" in a nested list. This is better because it makes diffing faster in the vdom. You have to make sure you never mutate so here is a way to "freeze" your objects which will make sure you don't do this. - 2017 Immer (I haven't used this yet): We realize it's a pain to change big objects if you can't mutate, so here is a dummy object you can mutate, we will clone it to make sure it's a different object. This is a proxy to the objects that will end up in your store (and exposed to your view layer). I understand how we got to needing Immer, but it's a solution to a problem we only have because of how frameworks like React figure out what changed (strict equality). But it's too verbose and error prone for us to do manually. React only got designed as it did because too many people got tired of OO style state management. Right now I'm noticing a lot of people are getting tired of the verbosity, boilerplate and complex abstractions that come with doing things the "proper React way" (updating state represented in an object is the main example here, but that whole chain is verbose: you need to create actions you can dispatch, you need to write a reducer to catch those actions and mutate your objects, you need to glue the correct state to each component). React is great tech, but in a lot of ways it's a counter movement. Countering complexities you get when managing state the OO way. But now it has gotten very complex itself, we now need a solution (immer) introduced by a solution (redux) that was needed to manage state inline with React. In other words, also very complex. It feels almost as if I took the Backbone code, renamed it and marketed as "a simpler way to manage your UI" I could get a lot of people to switch away from React + redux + immer + immutable + redux-thunk + etc...

acemarke 8y ago

FWIW, I've always felt that having duplicate / parallel "container" and "component" folders/files just for the sake of separating them is completely overkill. Most components are only connected once - just do that in the same file and export the plain and connected versions separately. I wrote some thoughts on that here: https://gist.github.com/markerikson/ea312b5ee398627ffceb09f89904831f https://gist.github.com/markerikson/ea312b5ee398627ffceb09f8... Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd like to have the tutorials and examples switch from a "folder-by-type" approach to either a "feature folder" or even a "ducks" approach, and maybe even cut down on having separate action constant variables. There's valid reasons to do things in multiple files, but it's also not _necessary_, and I want to simplify things. Yes, I totally agree immutable update logic is a pain to write and write correctly, which is why Immer is awesome, and why the starter kit uses Immer internally. My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. Please let me know how well it works for you, and if you've got any other suggestions for what it should include!

askmike 8y ago
Ah yes Immer is the framework I read about a few months back but couldn't find anymore. Thanks for reminding me. > My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. It's only a win since we decided that "mutation is bad" and we had to do spread notation gymnastics in all our es-2025 code that we are compiling to es5 anyway. From an abstraction point of view this is how I feel consensus about state management changed over time in the frontend world (or the part/frameworks I was involved in): - 2010: jQuery will help you update the DOM anywhere (looking at IE6) - but you have to solve state yourself. A deeply nested object attached at `window` was considered best practice. - 2012: We need to manage state properly, here is a nice Backbone "model" class: pass it a schema and use getters/setters to update so you can glue state change events to your view logic. - 2014: Angular (first version) is great! Don't worry about managing your state yourself, just attach whatever you want to $scope and we will simply use dirty checking to check everything whenever something changes. - 2015: React uses a vdom which behaves similar: change whatever you want and keep rendering it and React will figure out what actually changed. And for your state we made this flux thing which you implement as a bunch of different data stores (in my mind similar to backbone models except they only go "one way"). - 2016 (redux): here is a single store that also flows one way. Oh yea you need to do everything functional and you can't mutate any objects anymore or things will break. These 20 lines of code show you how to change the property of object with another property called id with value "x" in a nested list. This is better because it makes diffing faster in the vdom. You have to make sure you never mutate so here is a way to "freeze" your objects which will make sure you don't do this. - 2017 Immer (I haven't used this yet): We realize it's a pain to change big objects if you can't mutate, so here is a dummy object you can mutate, we will clone it to make sure it's a different object. This is a proxy to the objects that will end up in your store (and exposed to your view layer). I understand how we got to needing Immer, but it's a solution to a problem we only have because of how frameworks like React figure out what changed (strict equality). But it's too verbose and error prone for us to do manually. React only got designed as it did because too many people got tired of OO style state management. Right now I'm noticing a lot of people are getting tired of the verbosity, boilerplate and complex abstractions that come with doing things the "proper React way" (updating state represented in an object is the main example here, but that whole chain is verbose: you need to create actions you can dispatch, you need to write a reducer to catch those actions and mutate your objects, you need to glue the correct state to each component). React is great tech, but in a lot of ways it's a counter movement. Countering complexities you get when managing state the OO way. But now it has gotten very complex itself, we now need a solution (immer) introduced by a solution (redux) that was needed to manage state inline with React. In other words, also very complex. It feels almost as if I took the Backbone code, renamed it and marketed as "a simpler way to manage your UI" I could get a lot of people to switch away from React + redux + immer + immutable + redux-thunk + etc...