I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…
My struggle to learn React
181–190 of 218 posts
Re: My struggle to learn React
#182Earlier quoted context omitted.
Well, it really boils down to const path = findThePath(); class Router extends Component { render() { if (path === "/about") return else if (path.match(someRegex)) { const data = parseSomePath(path); return } else { return } } } Seems as though React Router has gotten a bit complex because it's abstracted away from the concept of a webpage, such that one can use it in the browser, or React Native (which can be a numb…
Just a small addendum to your post -- you shouldn't use react router for react native, you should use react-navigation for that ( https://reactnavigation.org/ ).
Re: My struggle to learn React
#183It appears that the biggest argument for React is:Facebook is using it. Really? PHP folks say they same thing: FaceBook is using PHP. There is article on how they write a custom PHP in C. When I view source of FB, it looks like SSR - and they are not using node. Maybe some small notification widget is sprinkled on top of PHP. But what kind of argument is: FB is using it? What is the FB reputation even? It is: who car…
Re: My struggle to learn React
#184Earlier quoted context omitted.
Redux itself doesn't actually care how you organize your file structure (per the FAQ entry at https://redux.js.org/faq/code-structure ). For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same…
See, the part we disagree with seems to be here: > so we try to keep it focused on the meaningful concepts. For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be. I'm not saying the docs should go into asides about the alternative structures all ov…
Re: My struggle to learn React
#185I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…
I haven't found a JavaScript framework that truly makes things easy. I've been a developer for a long time, going back even before the web itself, and a lot of the older technology was pretty easy in comparison to what we have today for web development. My impression of React is actually quite positive; it solves a real problem in a highly performant way and with a relatively good model. But it is still pretty low-le…
AngularJS 1.x + Angular-Material came close, but Google then released backwards-incompatible Angular 2.
Re: My struggle to learn React
#186Earlier quoted context omitted.
>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 funct…
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 {name} } function mapState(state, ownProps) { r…
- 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);Re: My struggle to learn React
#187Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even t…
This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers. This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that be…
So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state.
(We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.)
Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So:
1) there's no way they'd just rip it out of React without warning,
2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!
Re: My struggle to learn React
#188I've finally settled on Riot.js. It's easier in my opinion to consume in morsels and build up your development workflow anyway you see fit. I must say although the online documentation is good enough to get you going, I found the "Master Riot" course [0] was very helpful in synthesizing all the various concepts.
[0] https://www.udemy.com/master-riot/
Edit: Seems the course is no longer free but I think for $10, it's still very much worth it. Ray is a great instructor and really makes getting up to speed on the framework a breeze.Re: My struggle to learn React
#189Earlier quoted context omitted.
I think it is worth learning Elm first because it many ways it is much simpler. No JS "this" issues to worry about. No props vs. state. It is very opinionated. But it is also virtual dom and "component based" so the paradigm is instilled in the brain to go across and learn React. Disclosure: I learned some Haskell before Elm so I may be "immunized" against some of the struggle!
I don’t know, I think it’s better to just dive straight into what you’re trying to learn, otherwise you’re basically procrastinating.
For building understanding and mental models, I think it can be bad to jump into things that are too much of a struggle.
However the best of both worlds is some kind of tutorial that explains it really well. Like the recent "explaining functional programming to my 6 year old" article. Then you can dive straight in, but get off to a solid start.
Re: My struggle to learn React
#190Earlier quoted context omitted.
This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers. This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that be…
So our React site is fairly static, but as it grew we had more and more state to manage across components, and more of it trickling down; in some cases state would come from fairly high up in the structure, and have to be ingested pretty far down the component chain. So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 laye…
Old context will continue to exist through React 16.x, but will be removed in 17.0. Meanwhile, we've got a proof-of-concept PR open for React-Redux to switch it to use the new context API instead ( https://github.com/reactjs/react-redux/pull/898 ). Given the other changes related to React 16.3+, we're likely to put out a React-Redux 6.0 that includes the context usage changes, and make it 16.3+ only.
All that said: you really _should_ stop using the old context API, upgrade to React 16.3, and switch to the new context API instead. It solves the issues inherent to the old APIs design, and is the supported approach going forward.