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

My struggle to learn React

bradfrost.com

Post reply on HN
Print view View original

171–180 of 218 posts

Re: My struggle to learn React

#171

Post by tomc1985 »

hardwaregeek wrote: post #9

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…

I learned React before all these unnecessary addons and it was still borderline terrible. JSX and its school of thought is a horrible, horrible mistake and having to learn to use slightly-different names for everything (className vs class, etc) was infuriating.

Still, everything one needed for an SPA was there. With thoughtful design one didn't need any of those addons. Then, suddenly, Flux comes out and it seems like a few months later the whole scene says React+Flux is the only way to go. (I personally found Flux confusing as fuck, but I didn't give it more than 15 minutes) It amuses me to see some of these JavaScript proponents get so cocky over something that only lasts a couple of months.

Re: My struggle to learn React

#172

Post by keithnz »

daylightsavings wrote: post #42

I think this is the reason so many are picking up Vue rather than React or Angular these days. Vue offers the component approach and is generally fun to learn IMHO.

I have done both Vue and React projects. I like React philosophically. But my coworkers, who were keen to learn react, struggled conceptually and I ended up doing a lot of the React work. Then on another project we trialed Vue which worked out far simpler for people to learn and I also find I'm far quicker developing things using Vue. So while I'd tend to recommend Vue, I'd encourage people to trial both on something not too trivial before settling on either.

Re: My struggle to learn React

#173

Post by Izkata »

acemarke wrote: post #155
Izkata wrote: post #149

Earlier quoted context omitted.

> Say, if you keep you containers, reducers, and actions in their own directory trees. That layout is the biggest reason it took me so long to understand it when my team brought it in. It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful. We currently do this: state/ |---some_piece_of_state/ | |…

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 over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.

Re: My struggle to learn React

#174

Post by pg_bot »

ilikehurdles wrote: post #159
pg_bot wrote: post #61

Earlier quoted context omitted.

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…

>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) {
      return {
        name: state.name
      }
    }
   
    function mapDispatch(dispatch, ownProps) {
      return {}
    }

    export const HelloWorld = connect(mapState, mapDispatch)(_HelloWorld)

Re: My struggle to learn React

#175

Post by svnsets »

tptacek wrote: post #12

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…

Same here. Learning React for me was pretty simple. I think many get confused as to what React is and what it isn't. Like many view or template libraries, a React "app" is really just a function that takes properties and outputs markup. In React's case, there's a little more behind-the-scenes magic as to when changes propagate to the DOM, but the concept is still very similar. React isn't MVC/MVVM/MV*/etc, it just manages the view layer. With React, you also get the ability to render server-side and target other platforms such as iOS, Android, etc.

Redux on the other hand was a little more confusing for me to learn (the concept makes complete sense, it's the implementation and debugging that gets confusing). The great thing about Redux is that you don't have to use it or learn it. The React ecosystem is pretty well decoupled so you can choose how you want to manage state and async tasks. That is it's biggest selling point for me personally.

My experience with front-end frameworks started with Backbone + a ton of jQuery to AngularJS to React (with many different state management libraries). I found that Backbone didn't really provide much on top of jQuery + lodash/underscore, but I liked that it didn't make too many decisions for you. Angular (v1) on the other hand, forces you into some unconventional patterns (ie: the whole service vs factory fiasco and it's own dependency management system). It's fine if you aren't using a separate dependency management library (or ESM), but if you are, you have to declare dependencies twice. Angular 2/4/5/whatever-arbitrary-number-they-are-on-now has been way more confusing for me to learn as they make you learn their own templating language for things like loops, control flow, etc and still have some weird patterns around dependency injection. JSX is a lot simpler if you know basic JS. React seems to have the least amount of boilerplate code as well especially if you make use of functional components.

Re: My struggle to learn React

#176

Post by aarpmcgee »

klibertp wrote: post #102
the_new_guy_29 wrote: post #47

Earlier quoted context omitted.

This question is so wrong on so many levels

I have a blog. It's a set of static pages, generated offline and served via Nginx. There's nothing dynamic there and the content is perfectly readable in lynx. Once in a blue moon, I want to add a screenshot or other image to a post. Such images are of various sizes, mostly larger than the (max)width of the content. I use CSS to scale them down to fit with the text, but sometimes images displayed like that are too ti…

React and Redux are good at managing/coordinating lots of shared state. It sounds like you don’t have very much state.

Re: My struggle to learn React

#177

Post by rmrfrmrf »

pavlov wrote: post #144
poyu wrote: post #126

Earlier quoted context omitted.

Cross browser/backward compatibility, especially IE...

How far back do you need to be compatible? I'm pretty sure IE9 had all the necessary APIs, and it was released over seven years ago.

It's not just about compatibility, it's about implementation bugs. Even IE11 causes our larger apps enormous problems.

Re: My struggle to learn React

#178

Post by svnsets »

tptacek wrote: post #12

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…

I still have no idea what the right way to test things is

At my company, we use cucumberjs (https://github.com/cucumber/cucumber-js) to write scenarios for basic front-end testing. I wouldn't go overboard and start writing test to measure padding or font sizes, but you can easily see isolated scenarios and write automated tests to simply verify that a react component actually put the right element in the dom or to check conditional class names.

We also unit test many of our Redux reducers which is pretty simple with any unit testing library. Just create an initial state and expected state, call the action creator, and deep compare the new state with the expected state.

Re: My struggle to learn React

#179

Post by rmrfrmrf »

keithnz wrote: post #168
chrisco255 wrote: post #113

Earlier quoted context omitted.

Honestly, something like React/Vue has got to be as close as it gets to "The Final Paradigm". At this point, it's been a long time since I've seen a new paradigm that does anything vastly different or more productive and simple than JSX + React/Vue lifecycle & state hooks. Most of the new UI libs that come out (Glimmer, Marko, etc) seem to be heavily influenced by React and don't offer a giant leap in how UI is done.…

I don't think so, I'm thinking it's all about to change . why? WASM. We now see languages targeting the browser, and the beginnings of front end frameworks being developed in traditionally backend languages. I think this is going to create quite a different landscape for the web world in the next 5 years. Different languages bring different approaches to problems.

No reason why React couldn't be implemented in WASM. I'm less bullish than you are about WASM, though, since DOM interaction is going to be the bottleneck no matter which way you slice it.

Re: My struggle to learn React

#180

Post by handbanana »

TheAceOfHearts wrote: post #39

re: #5: At my previous job we wrote our own UI toolkit with React and css-modules. We had many dev-only views that we used to inspect and test our components. It worked great because it let you visualize all the states a component could have for a wide range of inputs, so you knew they were all being handled well. For example: If you get a long input prop do any of your styles break from visibility overflowing? If a…

This is pretty cool. But I've seen it done at a handful of companies. Where they have component libraries written in house. All those companies never open sourced their work - and it seems to me that it's a lot of reinventing the wheel
Post reply on HN