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

61–70 of 74 posts

Re: A SoundCloud client in React and Redux

#61

Post by acemarke »

davidjnelson wrote: post #36
girvo wrote: post #27

Earlier quoted context omitted.

> I question whether people use it in large scale production. We tried to, and removed it within 4 weeks of development with it, for all of the reasons you mentioned. It conceptually doesn't map to our Redux model, and new developers struggled with it because of that. I ended up writing my own "wrapper" to do something similar, but to be honest for most of our form state it is handled within the components themselves…

What are the pros/cons of setstate vs a batched state subtree for each component and an aggregate state subtree for each component that matched each form parent, specified by a string to a higher order component for the parent form and a string for each component used to model html5 form inputs?

Ah... you lost me on that statement. Can you give me an example of what you're picturing?

Re: A SoundCloud client in React and Redux

#62

Post by clarus »

babbeloski wrote: post #2

At work I've started keeping the reducer in the actions file, anyone else do that? This way they can share the same const declarations, and you don't have to toggle between two files when most actions / reducers are pretty small.

It seems that this is also the way of doing things in Elm (from which Redux is inspired): http://guide.elm-lang.org/architecture/index.html . The Update part groups both the definition of the actions and the reducers.

Re: A SoundCloud client in React and Redux

#63

Post by sorahn »

davidjnelson wrote: post #40
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. :)

While a super cool and important project, it's a ton of work to integrate into an app when you have maybe 3 sets of radio buttons to deal with, such as when doing an incremental migration refactoring.

>it's a ton of work to integrate into an app when you have maybe 3 sets of radio buttons to deal with

Untrue. It easily reduces the amount of code in your component, and actually gives you the ability to make your FormComponent as a stateless component.

https://gist.github.com/sorahn/6fac9f4717a81c96cd97e2bcc86a1...

Re: A SoundCloud client in React and Redux

#64

Post by CraigJPerry »

I look in src/ but nothing says SoundCloud client to me. I recognise the structure of this app as following current conventions but the logic is scattered by concerns I don't care about - e.g. I don't need a package called constants, I know what a constant looks like.

Concerns I do care about are hidden from me across files and package folders.

Re: A SoundCloud client in React and Redux

#65

Post by mercer »

icpmacdo wrote: post #18

The past few days I have really been getting into the 3REE stack: React, Redux and RethinkDB and have been learning so much. Here's a blog[1] outlining it and a github example of it [2]. It has been great so far, what are some UI libraries that I should take a look at, so far this looks like the best option[3] [1] http://blog.workshape.io/the-3ree-stack-react-redux-rethinkd... [2] https://github.com/GordyD/3ree [3] h…

I've been having fun using your stack along with RethinkDB's Horizon.io. Great way to get basic apps going!

Re: A SoundCloud client in React and Redux

#67

Post by tomduncalf »

Renner1 wrote: post #25
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…

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…

I've used it in a couple of form-heavy production projects and found it to be good, I find the API pretty easy to work with and it handles things like async validation pretty nicely (I use it in combination with yup for validating the form object: https://github.com/jquense/yup). I can honestly say it has almost made working with forms enjoyable ;)

A definite high point of my time with it was when a requirement came along to allow users to resume signup - because all the form state was in the Redux store already, it was simply a case of serializing that and putting it in localStorage (or wherever), then reloading it as the initialState.

There are performance issues to be aware of if your form gets too large, caused by the "top down re-render" effect of having the top level ReduxForm HOC connected to the form state and therefore re-rendering on every keystroke - often these can be solved by splitting the form into sub-components with appropriate shouldComponentUpdate etc., but this isn't a perfect solution - see https://github.com/erikras/redux-form/issues/123 for a lot of discussion. The new v6 API aims to solve this, by removing the need for a single top level component: https://github.com/erikras/redux-form/tree/v6

I've been intending to write up my experiences and how I've been working with it, but decided to hold off until the v6 API stabilised, so that I wasn't giving outdated advice. Happy to answer any questions in the meantime!

Re: A SoundCloud client in React and Redux

#69

Post by davidkpiano »

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…

I'm working on it, I promise!

I have been doing a LOT of work on forms in React and Redux, and have been putting all of my ideas into a library called React-Redux-Form: https://github.com/davidkpiano/react-redux-form

The premise is simple - your model state shouldn't be intertwined with your form state, and everything should be "vanilla Redux" -- that is, everything related to form state should be represented by actions and reducers, and not by some black-box API hidden inside a decorated component.

Version 1.0 is still in the works, but promises a lot of things such as making it MUCH simpler to get up and running with configuring the Redux store for forms, and also making smart optimizations that greatly improve performance.

My goal is to make forms as easy to implement as it was in Angular, and offer full flexibility to the developer to handle forms of various complexity.

Re: A SoundCloud client in React and Redux

#70

Post by tracker1 »

tracker1 wrote: post #59
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.

Just to expand... as an example...

    .../features/users/login
may contain both the ui components as well as specific actions/reducers related to login... though other components may call actions under features/user as necessary, because they correlate to the data/features/functionality around users, where the components themselves may be for other features.

I feel that once you stop trying to segregate by either component or type of module/script that it tends to be far easier for someone new to come up to speed in a project. It is taking practice and some thought, but has worked very well where I've implemented this approach so far.

Post reply on HN