Live data from Hacker News

Idiomatic Redux: Implementation and Intent

blog.isquaredsoftware.com

81–88 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#81
post #77

Earlier quoted context omitted.

> But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying , and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

You'd have a point if the article was intended for people trying to bootstrap a React stack but this is specifically a deep-dive on Redux. It's equivalent to people proselytizing Rust in any thread that mentions Go. Believe it or not some of us are not ignorant -- we know what MobX is and still choose Redux every time.

Actually it's a response to a response about using libraries to help with redux boilerplate. Depending on your scenario, mobx might reduce your boilerplate and your dependencies at the same time. That's absolutely appropriate context. And again while I appreciate not wanting to see those comments if you already know about mobx, not everyone does. I didn't. And I'll forever appreciate running into those comments myself. This isn't a go rust comparison (languages designed for different problems) -- it's a discussion about state management in a ui. I'm sure mobx won't be the only alternative brought up. Thats IMHO a good thing.

Re: Idiomatic Redux: Implementation and Intent

#82

This article serves only to reinforce that the beautiful simplicity of react is spoilt by the confusion of Redux. I feel that every Redux blog post should start by pointing out that despite react/Redux almost being discusssed synonymously, as the author of Redux points out, "you might not need Redux". I would go further and say "avoid Redux until you know you need it", and point people to more simple ways of reaching…

>Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path. I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with, To me, the fact that actions dispatched in whatever component would cau…

> I've seen this expressed many, many times, and it is something that I've honestly never quite understood.

Well, if you're coming in from a non-FP background, learning Redux is intimidating. I'm a aspiring web developer (I'm coming from tech support role and my programming skill is mostly bash and bit of Python) and started looking into Redux, and yay struggled with getting started.

  const store = createStore(reducer)
Took me hundreds of console.log ('entering func blah blah') before I realize out that those reducers become properties of the object store. So yes, Redux is power tool for expert and not as nearly accessible to your average neighborhood web developer.

Re: Idiomatic Redux: Implementation and Intent

#83

Earlier quoted context omitted.

>Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path. I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with, To me, the fact that actions dispatched in whatever component would cau…

> I've seen this expressed many, many times, and it is something that I've honestly never quite understood. Well, if you're coming in from a non-FP background, learning Redux is intimidating. I'm a aspiring web developer (I'm coming from tech support role and my programming skill is mostly bash and bit of Python) and started looking into Redux, and yay struggled with getting started. const store = createStore(reducer…

I'd be very happy to discuss any pain points or particular problems you've run into trying to learn Redux, and any suggestions you might have for improving the docs to make it easier for others in the future. Please feel free to ping me on Twitter, or in the Reactiflux chat channels.

Re: Idiomatic Redux: Implementation and Intent

#84
post #60

Earlier quoted context omitted.

It's no real secret that the author is a sucker for attention. I've always kind of felt that it was the first goal, and that he happened to help people was kind of a nice side effect. From spamming his links everywhere he can, to begging for upvotes on Twitter, going by posting stuff about how he got famous and constant bragging, it's not new.

This is utterly ridiculous. Mark is often found on, for example, the react subreddit helping out folk with redux problems, and it's not at all an efficient or practical way to gain a following. If he were focused on fame and glory, he'd do much better simply writing Medium articles to a large audience and spamming social media links. These kind of comments are disappointing to read, especially when directed at someon…

off-topic - I was always wondering if they have a life those heroes who spend enormous amount of time helping other people in reddit, stack overflow and github..

Re: Idiomatic Redux: Implementation and Intent

#85

Earlier quoted context omitted.

My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.

The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at https://github.com/markerikson/react-redux-links/blob/master... .

I have done both approaches, ducks, slight variation on ducks all running on production apps. Still not satisfied.

I have referred your links. Thank you btw.

Re: Idiomatic Redux: Implementation and Intent

#86
post #43

Earlier quoted context omitted.

The problem with redux is actually the dev-tools (and the ecosystem that spawned from the middleware). the newbies get wowed by "time travel debugging" and want to copy/paste there way to the $$$profit. Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state a…

Another red flag on redux: recommended practice--query JSON over HTTP (likely backed by an RDBMS), renormalize the hierarchical data, and then reshape the renormalized data before passing to components.

Right?! and redux is a baby-monster comparing to Relay that demands developer to actually modify the server's graphQL API in order to comply with the odd requirements.

Re: Idiomatic Redux: Implementation and Intent

#87

This article serves only to reinforce that the beautiful simplicity of react is spoilt by the confusion of Redux. I feel that every Redux blog post should start by pointing out that despite react/Redux almost being discusssed synonymously, as the author of Redux points out, "you might not need Redux". I would go further and say "avoid Redux until you know you need it", and point people to more simple ways of reaching…

>Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path. I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with, To me, the fact that actions dispatched in whatever component would cau…

My thoughts exactly!

The amount of things you need to know in order to use react and redux is ridiculously low.

You're basically just composing functions of two types "(state, action) => state" , and "state" => html.

The boilerplate consists of a few functions (really mostly createStore and connect) that are incredibly well documented.

There's almost nothing to understand and redux itself is almost not a lib (only 318 LOC). The whole thing is a pattern and redux is just a small, very well written key component of the pattern.

When people debate redux they debate about programming, not about a tool. That's why it's interesting and why it will never end.

Re: Idiomatic Redux: Implementation and Intent

#88
post #9

Whenever a Redux thread pops up, there's inevitably complaints about "boilerplate". I'd like to pre-empt those complaints a bit by pointing out that, per part 2 of my post, it's entirely up to you how much abstraction you use in your own Redux app. If you want use Redux for a particular use case, someone has probably already written an addon or utility to help solve that problem, and I've got them listed in my Redux…

Mobx is an alternative. Simple and less boilerplate.

There is not goodness or evil. There are the variant tools for accomplishing variant tasks. I tried to use Redux, but I didn't recognize how to easily build scalable apps. At the same time, I performed the task with mobX, really easy and with zest. But this is my case. You can get an opposite result
Post reply on HN