Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A SoundCloud client in React and Redux

robinwieruch.de

Post reply on HN
Print view View original

41–50 of 74 posts

Re: A SoundCloud client in React and Redux

#41

Post by idbehold »

JasonSage wrote: post #15
fpgaminer wrote: post #14

There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…

One small nitpick > let alone generating an entirely new state (because the state is immutable) Assuming you're talking about the redux state, this is only if the state changes. Dispatching an action to change the state of your form should cause the form's entire state tree to change at most, and possibly as few as one or zero objects. All those other redux reducers that just return the previous state are not going t…

It all depends on what's going on in the render method and/or shouldComponentUpdate.

Re: A SoundCloud client in React and Redux

#42

Post by acemarke »

firasd wrote: post #34
fpgaminer wrote: post #14

There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…

Your concerns about input events moving up and down the component tree seem misplaced. It’s what happens when you use React anyway (unless you’re only using local component state); putting these input values in the Redux store only makes things simpler. As for the fact that it changes the state and adds noise to the log… these seem like aesthetic judgments on your part. Why is changing an input “noise”? It’s an impor…

No, it's a pretty valid concern. If you assume controlled inputs, and you also tend towards putting all your state into Redux, that's exactly a use case issue you can see - every keystroke would, in theory, require a full round-trip through the store and back to the component, and also causing at least a `mapState` call and comparison for every other connected component along the way.

Re: A SoundCloud client in React and Redux

#43

Post by marshalltony »

davidjnelson wrote: post #31
Renner1 wrote: post #25

Earlier quoted context omitted.

I agree with your point and disagree with redux-form being a valid solution. redux-form creates a very restricted and crippled API for getting form data into a redux state object and does so at the expense of the spirit of React's componentized model. Any redux-form state needs to be isolated under a special root object specifically for forms. You can't just mount some existing part of your state object into a form b…

Also tried redux form and while the creator is very talented it was just more trouble than it was worth for our team. There's a real opportunity to create a sound abstraction to forms with react and redux right now. I've investigated this heavily and no existing approach works how I'd like. What I want is a higher order component for a given form parent specified by a string, with higher order components for all comm…

I think you need a new team if implementing redux-form was trouble...

Re: A SoundCloud client in React and Redux

#44

Post by firasd »

acemarke wrote: post #42
firasd wrote: post #34

Earlier quoted context omitted.

Your concerns about input events moving up and down the component tree seem misplaced. It’s what happens when you use React anyway (unless you’re only using local component state); putting these input values in the Redux store only makes things simpler. As for the fact that it changes the state and adds noise to the log… these seem like aesthetic judgments on your part. Why is changing an input “noise”? It’s an impor…

No, it's a pretty valid concern. If you assume controlled inputs, and you also tend towards putting all your state into Redux, that's exactly a use case issue you can see - every keystroke would, in theory, require a full round-trip through the store and back to the component, and also causing at least a `mapState` call and comparison for every other connected component along the way.

Here is a GIF of me putting input state (and general form state) in the Redux store: http://i.imgur.com/QRDH1Sy.gifv

Yes, if the keystrokes are not debounced it generates many actions. But my point is that concern about the ‘efficiency’ of moving events through components when using Redux is nothing compared to the byzantine way I had this implemented before using Redux. Trying to build forms in React without Redux or some other state solution, by just using setState and moving events and state up and down the component tree, will make you tear your hair out.

Re: A SoundCloud client in React and Redux

#45

Post by marshalltony »

Koromix wrote: post #33
Lazare wrote: post #19

Earlier quoted context omitted.

Everyone basically just uses Redux Form ( http://redux-form.com/5.2.5/ ) as near as I can tell; it really works well. It basically works as per your first guess: Everything goes in the store. And no, it doesn't really have any performance or efficiency issues. Try it out and see. :)

The overhead for a simple textarea seems significant. On Firefox there are stalls (up to 500 ms) if I type "fast". I've tested the form on http://redux-form.com/5.2.5/#/examples/simple?_k=8ukhm8 (specifically the textarea). Here is the CPU time graph during my tests: http://imgur.com/we9uGQ7 EDIT: OK apparently it's not accurate, see comment below.

He has redux dev tools enabled which might be causing issues with performance. We use redux-form for a medium project and have had zero performance issues. If you have huge forms you may run into performance issues but those are also gone in the new version.

Re: A SoundCloud client in React and Redux

#46

Post by jorde »

While Redux is much better than early Flux implementations, I feel that both have the same issues: quite a lot of boilerplate, scattered logic and confusion around best practices. Don't get me wrong, I really like Redux but I feel that most of the time I'm writing either boilerplate code or trying to decide how to structure my actions and reducers. Also combining actions/reducers with components isn't particularly easy given that you still need to combine reducers into one state. Not to talk about cherry picking parts of state into props and then working with reselect to cache values or normalize API responses...

Oh sorry, I think I had something that I needed to let out :)

Anyway, recently I discovered MobX[1] which, aside from the bad name, is amazing. It's pretty flexible and has very small API surface but compared to Redux it just gets out of the way. Granted, there's a lot of hidden logic which feels like magic but in the end it allows me to build apps way faster while still producing performant code. I have moved few projects from Redux to Mobx and it's mainly removing code and files and bundling mobx stores with components. At work I been able to explain it to coworkers in two minutes where as it has taken hours or days for people to understand Redux. I highly recommend checking out the React+MobX tutorial[2] and give it a go even though it's not the hot thing of the week just yet :)

[1] https://mobxjs.github.io/mobx/ [2] https://mobxjs.github.io/mobx/getting-started.html

Re: A SoundCloud client in React and Redux

#47

Post by fpgaminer »

Koromix wrote: post #33
Lazare wrote: post #19

Earlier quoted context omitted.

Everyone basically just uses Redux Form ( http://redux-form.com/5.2.5/ ) as near as I can tell; it really works well. It basically works as per your first guess: Everything goes in the store. And no, it doesn't really have any performance or efficiency issues. Try it out and see. :)

The overhead for a simple textarea seems significant. On Firefox there are stalls (up to 500 ms) if I type "fast". I've tested the form on http://redux-form.com/5.2.5/#/examples/simple?_k=8ukhm8 (specifically the textarea). Here is the CPU time graph during my tests: http://imgur.com/we9uGQ7 EDIT: OK apparently it's not accurate, see comment below.

Confirmed; just tested on my machine (Firefox, i7-3632QM @ 2.2GHz) by mashing on the keyboard. CPU spikes to 100% on one core and results in stalling.

In contrast the React+Redux app I'm working on uses the local Controller/Component state method and mashing on the keyboard there gave ~20% CPU.

I never would have imagined that Redux Form would lag on a desktop/laptop. I was more concerned that mobile performance would suffer. It's kind of impressive that a simple form can lag a desktop browser...

Re: A SoundCloud client in React and Redux

#48

Post by davidjnelson »

acemarke wrote: post #28
tzaman wrote: post #13

Nice tut, although I've learned one thing during past couple of months of developing with Redux: middleware is very useful and often quite an overlooked/underused part of the stack. In this tutorial, the author makes the call directly in an action, which is not its responsibility. Here's an example of the "api" middleware we've developed ( https://gist.github.com/tomazzaman/a98f5ad3f052592e564862e4d... ), and the bea…

Doing API calls inside async action creators / thunks _is_ entirely valid - in the end, it's still "creating actions". Just a question of how much duplication you want to deal with, consolidation, etc. But yeah, middleware is a concept that isn't talked about as much, but on the flip side, there's dozens and dozens of middlewares people have created. In fact, there's at least a couple dozen middlewares I've seen _jus…

And thunks for async get even sweeter with async/await/await*!

Re: A SoundCloud client in React and Redux

#49

Post by brentm »

lopatin wrote: post #22
fpgaminer wrote: post #14

There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…

For basic forms, where you're not doing something weird, why would intermediate form state need to live in Redux? Local React state seems best for that.

I agree with this. I've tried redux-form and just manually handling it with Redux but letting the form data live in the form's component state felt the most clean to me.

Re: A SoundCloud client in React and Redux

#50

Post by davidjnelson »

davidjnelson wrote: post #37
firasd wrote: post #34

Earlier quoted context omitted.

Your concerns about input events moving up and down the component tree seem misplaced. It’s what happens when you use React anyway (unless you’re only using local component state); putting these input values in the Redux store only makes things simpler. As for the fact that it changes the state and adds noise to the log… these seem like aesthetic judgments on your part. Why is changing an input “noise”? It’s an impor…

For me the batched changes are useful, but single character changes can make the event log overly verbose.

For the downvoter, you don't find single character changes overly verbose in the redux devtools monitor?
Post reply on HN