71–80 of 218 posts
React only gets complicated when you use states and mutable props, or when logic is put inside components.
As a view backend it just becomes a FSM translating app state into pure views and nothing more.
The takeaway I got is that it seems like the React stack has worse or non-existent separation of concerns and thus it'll affect how your frontend engineers work, possibly to their detriment if they're not proficient in javascript.
HTML, js and CSS aren't separate concerns. Each component is a separate concern.
Earlier quoted context omitted.
I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.
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…
So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there.
All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage.
Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
Obviously, react works for some people. It clicks with them. But I think a lot of folks prefer something with more clarity. Things change so fast that guides go out of date and devs/codebases fall behind on whats best practice. and this isn't without significant costs on the people who are trying to learn or maintain.
Conversely, Frameworks like Rails (My point is: It doesn't have to be this way. This mess is man-made and not beyond clean-up, but doing so may require some changes.
Part of the difficulty is trying to understand it all "from the bottom up", where you can't see the big picture because you're getting constantly tripped by ES6 vs. JSX features and trivial differences in component declaration syntax and whatnot. Instead you can learn it "from the top down" using React Studio:
It's an application modeling environment that lets you experiment visually with concepts like data binding and immediately see how it affects the resulting JSX code.
Because you're always working on a complete web app (rather than e.g. isolated components), it can be easier to understand the full picture of how things fit together. For example, you can start by simply placing some elements in a screen, then move them into a component of their own, then bind the contents of those elements to some props that come through the component, and finally use that component within a list that gets populated from a real data source. (Speaking of working with real data, there's a great plugin for Firebase Cloud Firestore [1] that lets you do realtime database reads and updates.)
Under the hood, the exported projects are using Facebook's create-react-app. There's no proprietary framework layered on top, it's just plain React with minimal dependencies (no Redux, etc.) There's also git integration and a rather elaborate plugin system, so you can modify the output and integrate custom code as needed.
This "top-down" approach isn't right for everyone, but might be a good fit for a UI designer skill profile. You get to build applications and learn modern JavaScript along the way by examining the output, rather than having to figure out everything from scratch.
(Disclaimer: I wrote a big chunk of the React Studio UI and code export.)
[1] https://hackernoon.com/the-easiest-way-by-far-to-build-a-rea...
This is a fine article. But I just want to say, as an alternate data point, my experience has been exactly the opposite . I love React. React is the first front-end technology I have ever managed to get to stick. * ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into somet…
>>* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem. But what happens when you inevitably need to step outside the boundaries set by create-react-app? From that perspective, it simply delays the problem, rather than solving it.
I've been writing Java for 20 years and never for a moment had the least doubt about the value of 'this'. ES6 has been slowly morphing into Java yet it hasn't solved this basic issue very well.
> 1. i haven’t invested enough time on learning it.
I usually find the types of tutorials Brad references in this section to be very bad at actually connecting with the real process of using a framework. What you're building is just as important as what you're building it with. When you find the right project to use the right tool, it helps the principals click so much more quickly.
> 2. react and es6 travel together
This is definitely a pain point but I think the crux of this is JSX. Most every other convention in React is a very straightforward use of ES6 syntax. Most of the awesome, difficult, but not broadly available parts (generators) of ES6 aren't used in React's public API.
> 3. syntax & conventions
I think React could benefit from a clearer breakdown of how JSX translates to actual JavaScript. Babel's REPL is a good first step. [0]
> 4. getting lost in this-land.
For the most part I've found React's use of JavaScript OOP and `this` to be the most sane. You can use what amounts to a bit of boilerplate in any component that needs state and use `this` within lifecycle methods without batting an eye. Backbone and Angular had all kinds of headaches when trying to explain `this` to junior developers. And don't get me started on libraries that used `this` to pass context around.
> 5. i haven’t found sample projects or tutorials that match how i tend to work.
I think React excels at matching his ideal workflow, but doesn't do a good job explaining how to achieve it. Higher Order components and smart/presentation components are very under-documented.
[0]: https://babeljs.io/repl/#?babili=false&browsers=&build=&buil...
Honestly 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 is exactly what the well-written official React docs do. It doesn't involve any CSS-in-JS, Redux, Thunking, Webpack, etc.
1) Start off with a basic app - build the Tic-Tac-Toe app through the official React docs
2) Build a simple React app with the official CRA (Create-React-App) tool
3) Build a more complex app
4) Keep building a more complex app, learn about routing, lifecycles, performance...
N) Look into Redux if you need it
---
Re. Redux:
The React docs have jumping off points throughout this process to understand why setState-based state management can get difficult in large applications (prop drilling) and the problems Redux solves. Look at this excellent doc on 'Lifting State Up' (https://reactjs.org/docs/lifting-state-up.html). This makes you go through the motions of setting up a component with setState, lifting state up, and experiencing prop drilling. Redux isn't even mentioned here.
Re. Thunking:
In the 'Basics' section of the Redux tutorial (https://redux.js.org/basics/actions), here's an excellent snippet: "Action creators can also be asynchronous and have side-effects. You can read about async actions in the advanced tutorial to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions."
Re. Reselect:
Again, in the Basics section, in "Usage with React" (https://redux.js.org/basics/usage-with-react): "These are the basics of the React Redux API, but there are a few shortcuts and power options so we encourage you to check out its documentation in detail. In case you are worried about mapStateToProps creating new objects too often, you might want to learn about computing derived data with reselect."
None of these 'power options' and extra tools are talked about in depth in the Basics sections of any of these docs. They are mentioned as jumping off points and the reader is warned not to dive into them early without continuing with the tutorials/docs. This seems to be exactly what you're looking for...