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

Show HN: Build your first real world React.js application

academy.plot.ly

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Show HN: Build your first real world React.js application

#21

Post by Arnavion »

roughcoder wrote: post #10
ng12 wrote: post #8

Earlier quoted context omitted.

First, this code could be cleaned up a little. The action types should definitely be constants -- something like ActionTypes.CHANGE_LOCATION. Using lodash's _.defaults is also a lot more terse than Object.assign. And if you're a real stickler for minimalism: https://github.com/acdlite/redux-actions#handleactionsreduce... The real power of reducers is composability. For example, I would almost certainly store the "sel…

If you support ES6/ES7 in your build cycle then we are big fans of the spread operator which can be used instead of _.default, Object.assign. For example: case 'CHANGE_LOCATION': return { ...state, location: action.location }

Note that object spreading is neither an ES6 nor an ES7 feature. It is currently at stage 2 - https://github.com/tc39/proposals#active-proposals "Rest/Spread Properties"

Re: Show HN: Build your first real world React.js application

#22

Post by yawgmoth »

hamandcheese wrote: post #20
ht85 wrote: post #6

Earlier quoted context omitted.

> when you can just have real functions doing setState() updates on the relevant component Using Redux, all or almost all of your state is stored in a global repository (the "store"). Those strings should probably be constants instead, especially for IDE auto-complete purpose, but you are never generating those manually. Instead, your components would call "action creators", who are properly named functions, which in…

Is it acceptable to dispatch inside your action creators? I'm somewhat new to redux but I got the impression that dispatch should be used inside mapDispatchToProps.

It's an example of the thunk pattern. Thunks are used when you have an async call, e.g. getFoos. Then your action creator would be

  function requestFoos() {
    return { type: REQ_FOOS }
  }

  function gotFoos(foos) {
    return { type: GOT_FOOS, foos }
  }

  export function getFoos() {
    return function(dispatch) { 
      dispatch(requestFoos());
      myFooProvider
        .getFoos()
        .then(function(foos) { dispatch(gotFoos(foos)); });
    }
  }
Really useful for writing reducers that want to keep track of when you're fetching data from the server.

Re: Show HN: Build your first real world React.js application

#23

Post by yawgmoth »

trnmura wrote: post #5
pavlov wrote: post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

I find this string pattern terrible as well. As the application grows, there are lots of reducers with lots of strings, and it gets really confusing. It feels like this is inherited from Flux ( https://facebook.github.io/flux/ ), Facebook's initial solution to handling state. On the other hand, you have all the state logic on reducers... If actions were to dispatch state-modifying functions, it wouldn't take long for…

It's not so bad if you keep your exported consts in a file with JsDoc comments.

Re: Show HN: Build your first real world React.js application

#24

Post by dandelany »

trnmura wrote: post #5
pavlov wrote: post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

I find this string pattern terrible as well. As the application grows, there are lots of reducers with lots of strings, and it gets really confusing. It feels like this is inherited from Flux ( https://facebook.github.io/flux/ ), Facebook's initial solution to handling state. On the other hand, you have all the state logic on reducers... If actions were to dispatch state-modifying functions, it wouldn't take long for…

I'm not sure why everyone is getting hung up on the fact that this is implemented with strings and a switch statement. Who cares? Use constants. If JS had enums we would use them, but it doesn't.

The point is that there are a finite, well-enumerated set of possible state changes, which are all localized in one place: the reducer. Whether you call them "DO_THING" vs. constants.actions.DO_THING (which could be an integer or whatever you want) or whether you use a switch statement vs. if block vs. dictionary lookup is entirely up to you.

Re: Show HN: Build your first real world React.js application

#25

Post by dandelany »

pavlov wrote: post #15
justinsaccount wrote: post #12

Earlier quoted context omitted.

It's nicer for more complicated applications. Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition. This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state. Since the UI should just be a function of the store this…

But is the UI just a function of the store? (I guess "store" in this context means the model data that is persisted on the server -- sorry if I'm getting the terminology wrong.) For example, something like selection typically isn't part of the model. (Users don't expect to undo a selection in an editor.) That means components will need to manage that kind of transient state internally, and the whole "UI is just a fun…

The UI can be purely a function of the store state, or not; whichever makes more sense in your project. I find it useful to use transient component state (ie. setState) also, for things like you mention - selecting something or keeping track of the "isOpen" state of a dropdown. Any state which does not need to live longer than the UI itself.

> the whole "UI is just a function" paradigm kind of breaks down.

Not really, it just goes from "UI is a function of the store state" to "UI is a function of the store state AND the component's internal transient state". Since internal state should only be modified by the component itself calling setState, this doesn't really add much complexity - in fact it usually reduces app complexity by obviating the need for a complicated global state structure for storing eg. the open state of every possible dropdown on the page.

Re: Show HN: Build your first real world React.js application

#26

Post by swsieber »

pavlov wrote: post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

I remember reading comments about this in the past year or two - many people have seen the similarity between this and Win32 event loops...

Re: Show HN: Build your first real world React.js application

#27

Post by sotojuan »

dandelany wrote: post #24
trnmura wrote: post #5

Earlier quoted context omitted.

I find this string pattern terrible as well. As the application grows, there are lots of reducers with lots of strings, and it gets really confusing. It feels like this is inherited from Flux ( https://facebook.github.io/flux/ ), Facebook's initial solution to handling state. On the other hand, you have all the state logic on reducers... If actions were to dispatch state-modifying functions, it wouldn't take long for…

I'm not sure why everyone is getting hung up on the fact that this is implemented with strings and a switch statement. Who cares? Use constants. If JS had enums we would use them, but it doesn't. The point is that there are a finite, well-enumerated set of possible state changes, which are all localized in one place: the reducer. Whether you call them "DO_THING" vs. constants.actions.DO_THING (which could be an integ…

I'm not sure why but a lot of developers think or are taught that switch statements are old fashioned or even bad.

Re: Show HN: Build your first real world React.js application

#28

Post by biscarch »

pavlov wrote: post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

It is possible to use Symbols instead of strings, which yields some nice improvements in terms of no longer allowing construction of actions with potentially misspelled strings, etc.

Re: Show HN: Build your first real world React.js application

#29

Post by licyeus »

pavlov wrote: post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

It's unfortunate that the Redux docs have led many (including myself) to think that Redux reducers means "switch statement". See http://redux.js.org/docs/basics/Reducers.html under "Note on switch and Boilerplate".

Your reducer can be whatever you want it to be as long as it does not produce side-effects. I use something like https://65535th.com/move-away/

Additionally, as roughcoder points out elsewhere in thread, using the object spread syntax (available in babel-preset-stage-2 or babel-plugin-transform-object-rest-spread) minimizes some additional boilerplate.

Re: Show HN: Build your first real world React.js application

#30

Post by ramchip »

sotojuan wrote: post #27
dandelany wrote: post #24

Earlier quoted context omitted.

I'm not sure why everyone is getting hung up on the fact that this is implemented with strings and a switch statement. Who cares? Use constants. If JS had enums we would use them, but it doesn't. The point is that there are a finite, well-enumerated set of possible state changes, which are all localized in one place: the reducer. Whether you call them "DO_THING" vs. constants.actions.DO_THING (which could be an integ…

I'm not sure why but a lot of developers think or are taught that switch statements are old fashioned or even bad.

Probably because programmers new to OO tend to use them when inheritance/interfaces would be cleaner (case cat, case dog, etc.)
Post reply on HN