this is a relatively terrible explanation of redux when compared to this: https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...
How Redux Works: A Counter-Example
51–60 of 84 posts
Re: How Redux Works: A Counter-Example
#52Earlier quoted context omitted.
This paradox I think is what turns people off Redux when they first learn it. "All this code... for what benefit?" Of course it's total overkill for something like a counter, or a todo list, but it's tough to teach an introduction to something by starting with "here's a huge enterprise app, let's dive in" :) I tried to call this out in the article to make sure people are aware that improving simple Counter examples i…
I understand the value of redux but I'd lump it in with git as an invaluable and elegant solution with a terrible interface. The structure is very confusing up front and makes no sense to an outsider. I learned react in about 15 minutes because it's so intuitive, but redux keeps making me scratch my head. IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willi…
Can you clarify what you mean by "terrible interface" for Redux? What structure is "confusing"?
Is this a concern with docs, the core Redux store API, the React-Redux API, or something else? Any suggestions for how we can improve things?
Re: How Redux Works: A Counter-Example
#53this is a relatively terrible explanation of redux when compared to this: https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...
Lin Clark's cartoons are always excellent, but these articles serve different purposes. "A Cartoon Intro to Redux" is more about the conceptual aspects, while Dave's post is both concepts and actual code usage.
Re: How Redux Works: A Counter-Example
#54Earlier quoted context omitted.
I disagree. It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is…
If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.
I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:
https://github.com/arximboldi/lager/issues/1#issuecomment-34...
Re: How Redux Works: A Counter-Example
#55There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary. I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undiscipl…
>> it appears hugely over complex and unnecessary Which it is, actually! Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not. When programming JavaScript SPA, you can program in the style of MVC also.…
In the apps that I've built, having many components manage their own private state makes it hard to coordinate said components, because all of the application state is stuffed inside different jars that you can't easily peak into.
It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.
I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.
So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.
Re: How Redux Works: A Counter-Example
#56I'm a Redux maintainer, and this is a great introduction to Redux. I love Dave's ability to break things down into easily understandable pieces, and his clear writing style. I also saw a similar "React and Redux: An Introduction" tutorial published just within the last couple days [0]. For anyone who's looking to learn more about Redux, I'd encourage you to check out my React/Redux links list [1], which has sections…
Is there is a similar repo of links for redux, specifically as it works with Angular? Thanks!
Re: How Redux Works: A Counter-Example
#57Earlier quoted context omitted.
It's downright embarrassing to walk through a Redux-using project with someone competent who's not immersed in the JS world. Source: had to do this recently. It helps if you translate "action creator", "action", and "reducer" to terms that are less misleading in the first two cases, and less uselessly-generic in the last one, but only a little. I tolerate it for basically "no-one got fired for buying IBM" reasons, i.…
I would expand that to say, it's embarrassing/difficult to explain the JS ecosystem to experienced non-JS devs. From "why are there 132MB of packages for hello world?" to "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI". Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for bu…
As an old-school Java dev that's been pulled into the JS world kicking and screaming, I can say that I have a pretty good appreciation for most of the complexity around modern FE builds. NPM legitimately kinda sucked up until the last few releases and is now stabilizing. I get functional programming. I even advocated for react when it was new because it felt so natural and powerful. Redux (or really react-redux) just hasn't hit that sweet spot. That being said I've seen it be hugely successful on big projects.
Re: How Redux Works: A Counter-Example
#58There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary. I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undiscipl…
I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase. Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a prett…
Earlier this year, I opened up an issue to get community discussion and feedback on ways to "reduce boilerplate" and make the getting started experience easier: https://github.com/reactjs/redux/issues/2295
The discussion trailed off, but I'd love to get additional feedback and ideas on ways we can improve things and build easier-to-use abstractions on top of Redux. (Or, even better, get some volunteers to _help_ us build better tools for getting started.)
Re: How Redux Works: A Counter-Example
#59Earlier quoted context omitted.
I understand the value of redux but I'd lump it in with git as an invaluable and elegant solution with a terrible interface. The structure is very confusing up front and makes no sense to an outsider. I learned react in about 15 minutes because it's so intuitive, but redux keeps making me scratch my head. IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willi…
Can you clarify what you mean by "terrible interface" for Redux? What structure is "confusing"? Is this a concern with docs, the core Redux store API, the React-Redux API, or something else? Any suggestions for how we can improve things?
I think it's mostly react-redux. There's arcane boilerplate in the connect function, mapDispatchToProps looks like a leaky abstraction, actions being passed as objects with a string in them is super brittle.
I don't have a fix, but I think just being able to inject a link to the store and then having an API that can be manipulated directly from the component would more comprehensible and cut down on the layers of indirection. I typically see corresponding action, reducer js file for a component when 95% of the logic is already in the component. Just merge them.
Re: How Redux Works: A Counter-Example
#60There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary. I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undiscipl…
> Once you understand the pains of undisciplined, organically designed, spaghetti applications, the cynicism is replaced by excitement over how this will improve your job/life/application. Beautifully said. The same goes for schema-less data models. The full appreciation of foreign keys, data type validation, and check constraints doesn't kick in until you try incrementally changing a NoSQL spaghetti app.
Similarly, I've always liked javascript's dynamic and flexible nature, especially for ui programming where requirements evolve quickly and dramatically. But now that I've got a big redux app that is on a pretty steady course, I'm starting to see the value that static types would bring. A lot of the mental overhead of working with the codebase now consists of remembering the exact shape of all the data, which properties are defined on which actions, etc. Before too long I'm going to have to give Typescript, Flow, or something along those lines a serious look just for the sake of having it all defined in one place.