5 ms·

Some unsolicited advice from someone who has also been down a similar path. I normally suggest eschewing the javascript class model in favor of using stateless

by pg_bot 8y ago

Some unsolicited advice from someone who has also been down a similar path. I normally suggest eschewing the javascript class model in favor of using stateless functional components.[0] I've found them simpler to understand and it cuts down on unnecessary typing. I almost never use 'this' in javascript, and instead have favored an OLOO[1] or pure functional style as it fits into a simpler mental model for how things are working. I normally only test the actions that modify state in my javascript applications. I care that I'm correctly changing the state of my application, not what that state renders. (This is similar to rails apps not typically testing html output) I normally use mocha[2] for testing and if something goes wrong I can open up a normal chrome js debugger using the --inspect-brk flag when running via the cli. You will eventually find yourself needing to support multiple routes in your react applications. Most people would recommend the "react-router" library, but I've found a lot more success with "redux-little-router"[3] [0]: https://reactjs.org/docs/components-and-props.html https://reactjs.org/docs/components-and-props.html [1]: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/ch6.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%... [2]: https://mochajs.org/ https://mochajs.org/ [3]: https://github.com/FormidableLabs/redux-little-router https://github.com/FormidableLabs/redux-little-router

allover 8y ago
And I 100% disagree. If you're new to React I strongly recommend sticking with classes and embracing React's 'component' model which is one of its strengths and which Redux + trying to use only stateless functional components throws out with the bathwater.
billdybas 8y ago
+1 for testing actions / reducers. Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle. For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out! [1]: https://github.com/supasate/connected-react-router https://github.com/supasate/connected-react-router
ilikehurdles 8y ago
>I normally suggest eschewing the javascript class model in favor of using stateless functional components. So I do this whenever possible, but the way this advice is worded (both here and often in the wild) makes it sound like you can just use them everywhere. Most UIs have state. I can't imagine a UI that doesn't. Every third component or so I write I end up using classes for, so I've got a mix of classes and functional components throughout the codebase. Do you _never_ use classes? If so, what do you do instead? Otherwise if you're like me, you get to use functional components occasionally which is nice, but are nowhere near being able to get rid of the class syntax.
- pg_bot 8y ago
  I only use classes when I need to use a ref within a component (which is quite rare). I use redux for all my state management instead of storing state within the component itself. Everything else is a stateless functional component. A typical component would look like import React from "react"; import { connect } from "react-redux"; function _HelloWorld({name}) { return <div className="intro">{name}</div> } function mapState(state, ownProps) { return { name: state.name } } function mapDispatch(dispatch, ownProps) { return {} } export const HelloWorld = connect(mapState, mapDispatch)(_HelloWorld)
  - acemarke 8y ago
    I realize this is just a snippet and probably written off the top of your head (rather than reflecting real code), but a couple quick suggestions for improvement there: - Only add the `ownProps` argument to `mapState` or `mapDispatch` if you actually need it, because `connect()` will now call those functions more often (whenever the incoming props have changed). If you're not actually _using_ values from `ownProps` in there, don't add those arguments. - The `mapDispatch` function isn't doing anything at all in that example, and can be omitted completely - I personally recommend using the "object shorthand" form of `mapDispatch` instead. To me, there's never actually a good reason to write a separate `mapDispatch` function. Just write action creators, and pass them in an object to `connect`, like this: import {addTodo, toggleTodo} from "./todoActions"; const actionCreators = {addTodo, toggleTodo}; export default connect(mapState, actionCreators)(TodoList);

by pg_bot 8y ago

allover 8y ago

And I 100% disagree. If you're new to React I strongly recommend sticking with classes and embracing React's 'component' model which is one of its strengths and which Redux + trying to use only stateless functional components throws out with the bathwater.

billdybas 8y ago

+1 for testing actions / reducers. Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle. For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out! [1]: https://github.com/supasate/connected-react-router https://github.com/supasate/connected-react-router

ilikehurdles 8y ago

>I normally suggest eschewing the javascript class model in favor of using stateless functional components. So I do this whenever possible, but the way this advice is worded (both here and often in the wild) makes it sound like you can just use them everywhere. Most UIs have state. I can't imagine a UI that doesn't. Every third component or so I write I end up using classes for, so I've got a mix of classes and functional components throughout the codebase. Do you _never_ use classes? If so, what do you do instead? Otherwise if you're like me, you get to use functional components occasionally which is nice, but are nowhere near being able to get rid of the class syntax.

pg_bot 8y ago
I only use classes when I need to use a ref within a component (which is quite rare). I use redux for all my state management instead of storing state within the component itself. Everything else is a stateless functional component. A typical component would look like import React from "react"; import { connect } from "react-redux"; function _HelloWorld({name}) { return <div className="intro">{name}</div> } function mapState(state, ownProps) { return { name: state.name } } function mapDispatch(dispatch, ownProps) { return {} } export const HelloWorld = connect(mapState, mapDispatch)(_HelloWorld)
- acemarke 8y ago
  I realize this is just a snippet and probably written off the top of your head (rather than reflecting real code), but a couple quick suggestions for improvement there: - Only add the `ownProps` argument to `mapState` or `mapDispatch` if you actually need it, because `connect()` will now call those functions more often (whenever the incoming props have changed). If you're not actually _using_ values from `ownProps` in there, don't add those arguments. - The `mapDispatch` function isn't doing anything at all in that example, and can be omitted completely - I personally recommend using the "object shorthand" form of `mapDispatch` instead. To me, there's never actually a good reason to write a separate `mapDispatch` function. Just write action creators, and pass them in an object to `connect`, like this: import {addTodo, toggleTodo} from "./todoActions"; const actionCreators = {addTodo, toggleTodo}; export default connect(mapState, actionCreators)(TodoList);