A SoundCloud client in React and Redux • Hacker News Board

Re: A SoundCloud client in React and Redux

#51

Post by groovytime » Mon, Jun 13, 2016, 1:59 AM UTC

fpgaminer wrote: post #47

Koromix wrote: post #33

Earlier quoted context omitted.

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 woul…

He has redux dev tools enabled, hence the performance issues.

Re: A SoundCloud client in React and Redux

#52

Post by ht85 » Mon, Jun 13, 2016, 2:00 AM UTC

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…

Most of the time I don't feel like performance is an issue as long as all your components use PureRenderMixin. Unless it takes over 20-30ms to render, the difference is not noticeable.

The problem as others have said is that it pollutes history, and that it is very CPU cycle hungry, bad for anything running on battery.

Nowadays I tend to use onBlur instead. There are two scenarios:

1) The form is the only source of change for the data. In this case just update the global state onBlur.

2) Other things affect the form value, so you need controlled input. In this case, onChange updates the local state. onBlur updates the global state and set the local state to null. Use ``

Re: A SoundCloud client in React and Redux

#53

Post by groovytime » Mon, Jun 13, 2016, 2:13 AM UTC

jorde wrote: post #46

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 ea…

Heaven for bid you actually have to understand how/why something works and not just have "magic" happen.

Re: A SoundCloud client in React and Redux

#54

Post by Glide » Mon, Jun 13, 2016, 2:32 AM UTC

jorde wrote: post #46

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 ea…

Mobx needs more love.

For flexibility I am leaning towards making MobX as a choice in projects and then being able to build up towards an architecture like Flux in an application.

Re: A SoundCloud client in React and Redux

#55

Post by Koromix » Mon, Jun 13, 2016, 2:32 AM UTC

groovytime wrote: post #51

fpgaminer wrote: post #47

Earlier quoted context omitted.

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 woul…

He has redux dev tools enabled, hence the performance issues.

Indeed it behaves much better on a demo I found elsewhere, sorry for the inaccurate comment.

Re: A SoundCloud client in React and Redux

#56

Post by lucidrains » Mon, Jun 13, 2016, 3:03 AM UTC

jorde wrote: post #46

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 ea…

Second this, mobx is awesome

Re: A SoundCloud client in React and Redux

#57

Post by davidkpiano » Mon, Jun 13, 2016, 4:07 AM UTC

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…

You should take a look at https://github.com/davidkpiano/react-redux-form - solves many of your problems listed (batches actions when possible to prevent log spam), and V1.0 will be even simpler/more performant.

Re: A SoundCloud client in React and Redux

#58

Post by antjanus » Mon, Jun 13, 2016, 4:22 AM UTC

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…

We use Redux where I work and we deal with a TON of forms, many of which are controlled completely separately from each other. Oh and it's an Angular 1 app and in production.

Basically what I've learned is that you have to distinguish between global and local application state. Redux doesn't have to know EVERYTHING that's going on in the application.

That means that when you're editing a piece of text, it depends on what you want from it. Are you showing word count in several places that aren't contextually related? (like a total word count up top on your page, and a local word count). If so, run it through Redux on every key down/key up event. Are you NOT using that information anywhere? Then skip Redux and pipe that edited text through only when a user hits "save".

The entire point of Flux was to have one source of truth for shared data in your app. If you're not sharing information, it doesn't have to be shoved into Flux/Redux. The example the FB developers brought up was reading messages. You have like 5 places that unread message count shows up: the little chat bar on bottom if you haven't read a message from a recent contact, notification bar up top, chat sidebar, and left sidebar (I think). Doing anything in any of those places should trigger a change: unread count drops when you open a chatbox with a person that left you a message for instance.

But if you're writing a message and you're looking at your character count (like on twitter when you're writing a tweet), that data doesn't need to be shared. It just stays in that textarea component.

I hope that makes sense! :)

Re: A SoundCloud client in React and Redux

#59

Post by tracker1 » Mon, Jun 13, 2016, 4:54 AM UTC

jorde wrote: post #46

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 ea…

Don't map your reducers/actions to the components... map them to the data/features they are tied to. If you organize by feature, you don't really have to have your actions/dispatchers sitting with your components, but you can where it makes sense.

Re: A SoundCloud client in React and Redux

#60

Post by stickperson » Mon, Jun 13, 2016, 5:37 AM UTC

antjanus wrote: post #58

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…

We use Redux where I work and we deal with a TON of forms, many of which are controlled completely separately from each other. Oh and it's an Angular 1 app and in production. Basically what I've learned is that you have to distinguish between global and local application state. Redux doesn't have to know EVERYTHING that's going on in the application. That means that when you're editing a piece of text, it depends on…

Autocomplete is another good example. Instead of having my autocomplete API call go through the whole dispatch -> reducer flow, I just update my component's state when I get a response.