> - Do not use redux until you know React well. You might not need it.
Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app..
I'm now using "unstated" for client store. What a breeze of fresh air!
As a back end developer, Redux had instant appeal to me, because I've written apps that managed state by generating events asynchronously, serializing them, and using each one to update state in turn, generating a series of discrete state snapshots that were used to serve read operations. In doing so I reinvented Flux without realizing it (as everybody does when they structure an application that way.) When I encountered Redux, its concepts mapped exactly onto the concepts I already knew, so it was easy to get started. I had written reducers before, though I didn't call them that. After previous brushes with front-end development, I was excited to have a clean conceptual separation between state management and rendering the DOM. Managing that relationship seemed to be a place where even expert front-end developers got lost, so I was happy to have a radically simple solution.
I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.
I recently wrote a post called "The History and Implementation of React-Redux" [0]. It covers the basic process of how Redux works with a UI, the benefits of using React-Redux, and the specific implementation details of how it optimizes React rendering updates for you.
I would be happy to show you how to use redux, without switch statements and even without reducers. It's not that hard, and if you don't like it, just use other state management libs. But don't call it poor design - it has 2 methods.
Can you point to any writeups on this? Would love to reduce the boilerplate a bit, while still needing a global state management tool for a smaller app.
Hi, I'm a Redux maintainer. Here's a few resources.
First, the docs already have a page called "Reducing Boilerplate", which shows patterns like writing a function that accepts a lookup table of reducers [0].
Second, a while back I wrote a pair of posts called "The Tao of Redux" [1] [2]. Part 1 discusses the implementation and intent behind how Redux is meant to be used, and Part 2 looks at why common usage practices exist. As part of that, I pointed out that you can use whatever logic you want in your reducers, and as much or as little abstraction on top of Redux. Switch statements are simply the most obvious way to handle multiple values for a single field, but you should feel free to use whatever approach you want.
Third, we've recently created a new package called `redux-starter-kit` [3]. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action types or action creators by hand. I'd encourage you to try it out and let us know how well it works for you.
Please let me know if you've got any other questions I can help with!
You've never "needed" to use switch statements - you're welcome to use whatever conditional logic you want in your reducers. Many people prefer to use lookup tables of functions to handle different action types.
Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work.
The point of `mapStateToProps` is to allow you to specify "here's the data this component needs from the Redux" store, so that `connect` can take care of the work of subscribing to the store and only re-rendering your component when it actually gets new data. See my post "The History and Implementation of React-Redux" [0] for more details.
Finally, please check out our new `redux-starter-kit` package, which helps simplify several common Redux use cases [1].
> separating the idea that "something happened" from "here's how the state updates in response" is key
The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and analyze.
The ideal? I want to define a function with its parameters and that function performs the logic and data massaging it needs to. When I want that behaviour to trigger because something happened, I want to describe a call to that function with the right parameters with minimal scaffolding. Ideally, it would look exactly like I call that function, and the machinery that would turn that into posting an action that eventually reaches a reducer would be hidden from my sight. I do not want that scaffolding polluting my code. Defining string names for my functions? They are functions, they already have a name. Defining action objects to store the parameters? I already have a place for that, it's called "function parameters".
I don't know what sort of magic could provide this seamless integration of the reactive patterns into javascript, sort of some transpilation machinery. But I really, REALLY do not want it visible in my code.
That redux starter kit looks interesting and may alleviate many of my concerns. I don't know if it will eliminate them, but thanks a lot for that.
[...edit...] Unfortunately, it looks brilliant with stuff like createSlice(), but it doesn't quite go far enough. If I have to deal with "action" and "payload" stuff then I am already polluting my code too much with stuff that I want to keep hidden in the machinery. My reducer functions should receive their actual parameters, not an "action" that they need to destructure into the actual parameters. And calling the actions in the slices should also wrap the store.dispatch() inside them. Ahhh feels so close to the ideal...
Reducers, by definition, take two parameters: the current state and the action. They should return an updated state based on those two inputs only. The `payload` field is simply a common convention for consistently putting the "arguments" or "data" for that action type at a known key in the action each time.
I'm also not sure what you mean by "calling actions should wrap `dispatch` inside of them".
Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this:
multiplyAdd: (state, action) => state * action.payload.a + action.payload.b
I want it to look like:
multiplyAdd: (state, a, b) => state * a + b
or even
multiplyAdd: (a, b) => this.state * a + b
Because that is exactly the function/logic I want to describe. The 'action' and 'payload' are part of the scaffolding for redux execution flow. 'action' will contain data in it with the actual parameters, when javascript functions already support receiving parameters. I want the benefits of redux without paying for it in code clutter.
There may be debate if this clutter is too much to pay or not, and that's fine. Plain redux imposes a lot more clutter and was still worth it for many people. My ideal is to reduce it to nothing.
Now, the second part:
store.dispatch(counter.actions.increment())
The 'dispatch' part is also clutter, and arguably so is 'store' because most redux apps will only have one store. So, I want that line to look like this:
counter.actions.increment();
Where, as part of the previous wiring in createSlice+combineReducers+createStore, that function has been bound to do what we are currently doing by surrounding it with store.dispatch().
What's more, for our multiplyAdd function with two parameters, I (guess) we would be calling it as:
For some it may be too much magic, but if you are in react-starter-kit territory I doubt it. For some it may be just me being pedantic and what the kit offers is already plenty, but the kit already moves away from plain redux and I just want to move it a bit further.
Oh, and of course I want it all to work with types in Typescript. :)
(I don't currently work with React or redux, so my ntoes are just a brain dump based on my past experience and expectations for future use, and certainly not a request, demand or criticism of redux or the kit).
Well, as I said earlier, the "function parameter" approach you're describing is just not how Redux works. You can only cause state updates by dispatching an action. An action is a plain JS object with a `type` field, and whatever additional fields you want. Your root reducer _must_ have a `(state, action) => newState` signature. Now, you can break up the internals of that reducer logic however you want, so I suppose in theory you could have some kind of "function parameters reducer factory" or something that extracts fields from the action, but that seems a bit silly to me (and it would also look really strange compared to all other Redux applications).
As for the dispatching approach, most of the time you'll be dispatching these actions from a React component, in which case it's going to look like `this.props.doSomething()`.
I will say that `createSlice` is currently limited in how it generates action creators. They currently only accept a single argument, which it turns into the `payload` field in the actions. If you're writing the action creators by hand, typically you could accept multiple function parameters in the action creator, and then combine those into a single `payload` object. The limitation is something of a tradeoff for not writing the action creators by hand. `redux-starter-kit`'s `createSlice` function was inspired by https://github.com/ericelliott/autodux , which lets you optionally pass in some kind of a "payload creation callback" function. It would be reasonable to do something similar in our `createSlice`, but that's also more code you'd be writing by hand.
> the "function parameter" approach you're describing is just not how Redux works
That's not how redux works internally, and it makes all the sense in the world. My wish is to keep these details buried and not leak into the coding style used by the app. The logic in my function wants two arguments, the fact that those two arguments have been packed into an action (and into a field named 'payload') to work with the redux flow of dispatching & etc is not something that anything in the logic or body of my function needs to know. It is necessary because of how redux works, but everything in the kit is about adding glue between app code and redux, reducing the verbosity and presence of redux internals in app code, so this sounds like a natural way to continue that trend.
If I was working with React these days I'd surely set out some time to try and extend the kit in those directions. A few years ago (shortly after redux was first released) I gave it a shot, but there were too many pieces to build. The kit does a great job lifting a lot of newly developed packages like immer.
You can do what you want just in 17 lines of pure JavaScript. This is an example:
const
create_store = ({state, actions}) => {
const
after_update_do = [],
subscribe = fn => after_update_do.push(fn),
notify = () => after_update_do.forEach(fn => fn(state)),
create_action = action => (...args) => {
state = action(state, ...args);
notify()
};
return Object.entries(actions).reduce((bound_actions, [action_name, action]) =>
Object.assign({}, bound_actions, {[action_name]: create_action(action)}),
{subscribe})
},
counter = create_store({
state: 0,
actions: {
increase: state => state + 1,
decrease: state => state - 1,
multiply_add: (state, a, b) => state * a + b,
},
});
counter.subscribe(state => console.log('First reactive component was updated with: ' + state));
counter.subscribe(state => console.log('Second reactive component was updated with: ' + state));
Now you can call all actions directly from the counter and update all components in reactive manner.
counter.increase();
// First reactive component was updated with: 1
// Second reactive component was updated with: 1
counter.multiply_add(2, 3)
// First reactive component was updated with: 5
// Second reactive component was updated with: 5
Redux still baffles me. I've implemented it 4 times, and it still confuses the hell out of me.
MobX is a much better fit for most react apps IMHO. Redux could be good, if you have a database [id] driven application, but for most people is way too restrictive.
If you are working in a small team, and are using Redux, you are probably making life harder than it has to be.
When Redux stops to buffles you, might be the good time to give advice about it. You might implement it 20 times, but if you don't understand it, every time will be pain. Redux can be life saver even for single developer, so team size dosen't matter.
Would be funny to say, I've tried 4 times to tie my shoes, but didn't go well, so you shuldn't tie your shoes...
So much hate, whithout any reason is what buffles me.
This is the point of redux. If you don't have these restrictions, then state will be all overt the place, race conditions, side effects will make your life much harder as the app matures especially with multiple developers.
No, not right. I have work on a daily base with redux unfortunately. Redux is not too hard, but it's poor in design. Also you will have to give up redux soon, the hype is over and better things are at the horizon.
There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Try unstated, or is that too simple for you? Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
Wow. What an incredibly ignorant and embarrassing point of view.
> Redux is not too hard, but it's poor in design.
You have not once yet stated why it is "poor in design".
> Also you will have to give up redux soon, the hype is over and better things are at the horizon.
I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality.
> There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer.
You are projecting a point of view onto me that I do not hold. Does this argument tactic usually work?
> Do you really think redux is the holy grail of stores?
No. I do not hold it in higher regarded than what I believe is merited.
> If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Once again, you say that "it sucks" without giving a valid reason. Do better.
> Try unstated, or is that too simple for you?
Unstated? If you mean "stateless", then I'm not sure what there is to try. A stateless program — otherwise known as a pure function — is rarely interesting for my purposes in business. In all cases, my programs required some persistent state to be modelled.
> Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
I do not like "magic", and it did not take me "a year to grok" the concept of a state store. Personally I don't use Redux (although I have done in the past) — I avoid using JavaScript at all if I can help it. Where I need complex UIs, I use Elm. Redux is a JavaScript state store heavily inspired by Elm. It's basically the same, minus type safety (so it's worse).
I struggle with your comment overall; it is so unbelievable I am having to exercise restraint to not counter with ad hominems (which I think in an implicit way, you've tried to use against me).
Wow, relax man! You don't have to defend redux with your life!
I have to work on a daily base with redux because almost every stupid company is using that nowadays. Some codebases are so horrific that I simply quit the job and find something better.
I actually said why it is poor in design: endless switch statements with reducers, do you think that is great design? Every component that wants to use a store needs to 'connect' to it with a higher order component, ever seen chains of hoc's and still know what's going on? Then you need to write time and time again mapStateToProps and mapDispatchToProps. Do you think that's great design? Even if there would be no other state management system yet, it still sucks. Even Dan Abramov says you probably don't need redux, still everyone is using it for the most simple apps.
You might want to use a router, well you're kinda locked into redux so you need redux-router. Example from the redux-router repo:
import React from 'react';
import { combineReducers, applyMiddleware, compose, createStore } from 'redux';
import { reduxReactRouter, routerStateReducer, ReduxRouter } from 'redux-router';
import { createHistory } from 'history';
import { Route } from 'react-router';
This, for just wanting to use a fucking router that works along with my store! You think that is great design? React is great design IMHO, not redux. Dan Abramov is a great guy, highly talented, times more intelligent than I am, but his design principles are really poor. Same counts for hooks, a fun experiment for a counter demo, but poor design for larger apps. I hope it will never become a hype too.
Redux is just one of the many flux implementations. Not the best, but a flavour that you may like or dislike. Unstated is a client store that is a wrapper around the new React Context API: unstated: https://github.com/jamiebuilds/unstated
Redux is not "poor in design", rather "poor in implementation". The idea is good, a true single input->update->render cycle, but the reality is tons of boilerplate and stringly-typed code.
I know, you can easily improve it, but from the beginning the docs and most popular helper libaries all point you in the wrong direction.
Can you point to any specific concerns with the docs? We're planning to revamp them in the near future [0], and I'd appreciate any feedback that can help us improve them.
First, there is no guarantee that a backend and frontend developer together perform better than 1 full stack developer. It really depends on who's doing the job. I'm a full stack JS developer, and yes I can do pretty awesome CSS if needed, or is that considered to be impossible?
Btw, how would the author go about building a nodejs SSR React application? 1 backend, 1 frontend and 1 HTML/CSS guru? I've actually never seen that, even in large companies.
I see there is some frustration about CSS in JS while writing in object notation is not any more difficult than CSS or SCSS, my 12 year old daughter would learn that in a snap. I can imagine it is frustrating for people that are good in HTML and CSS that there is not much work if you cannot actually code, but that doesn't mean there is a problem with full stack.
Python almost became my main language, but I moved to another language when I saw it was stuck at 2.7. Another reason was the lambda's only allowing 1 line instead of the flexible closures in so many other languages. And my expectations for future improvements were very low as the core maintainer looked quite stubborn to me.
Pretty much how I ended up doing most of my coding in Groovy. I essentially wanted Python. But Python wasn't a good enough Python. (being honest, other things attracted me to Groovy as well - Java ecosystem etc, but it's interesting to me that in the larger picture, I'm sort of using Groovy as a proxy for a Python without Python's flaws).
This should not be a discussion about Australia or any government in particular. The discussion should be about the importance of not supporting closed source.
I believe in open-source. This just proves once again that closed source cannot be trusted. I would never use 1Password or any of it's variants. It still amazes me that so many people are sending their most precious secrets to a commercial companies' cloud server.
I only use Keepass open source password manager, every day for over 9 years now, and I'm really thankful to the devs that build and maintain this nice piece of software.
I'd prefer React even more now with the promising Hooks. I would not easily let a random person here choose for me with all his/her opinions. It really depends on what you want to do with either library.
For work/income I'd choose React as there seem to be more jobs for that. Also in the long term it feels like a pretty solid choice. React has a very big and active community, an outstanding development team, and so many codebases in the world are build on it. React will linger on for quite a while I dare to guess.
IMHO it is not really a React vs Vue thing, you could also go for Ember or Angular. Just pick the one that feels and works good for you and fulfils your personal needs we cannot assess.
Ideally register the company when there's something to show. Even if the company has been registered, this is where vesting kicks in. Agreed that it's probably harder to fire one, and worst case, you might have to abandon the company and start a new one.
I know that most people won't build things for "equity" but it is a form of investment for the technical co-founder. That said, a lot do take salary as well as equity, and it's a balance between which they prefer.
There are some benefits - like being easier to gain investor confidence, if you do have a technical founder. I think that makes it worth it.
I like the idea. Only the (very few) available books require even in my own language a pretty advanced level. I would use this for sure if the reading level of the books available would be more for children so I can learn words and sentences that I can actually use and practice in daily life.
Because of legal reasons we can only have books from the public domain. If you know some that are free, just point me to them and I'll match them for you. I need them to be in .epub format for both languages.
Does this refer to the company pretending they deserve better than you? I've seen enough incompetent people at companies declining good candidates because they are simply unable to recognise it. I've seen so many shitty companies pretending they are top tier, it's just the arrogance of power. Only once you're in you can see the flaws and mess it often actually is.
> Blockchain is also the driving force behind cryptocurrencies, allowing Bitcoin owners to purchase drugs on the internet without the hassle of showing their identity. So, if that sounds like you, then yes, you should consider using blockchain.
Oh my, this is soo opinionated and short sighted, it starts with complete rubbish, pointless read I guess.
Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app..
I'm now using "unstated" for client store. What a breeze of fresh air!