React Fundamentals: What I’m Learning

https://buaiscia.github.io/posts/learning-on-epic-react-fundamentals

by buaiscia • 6 years ago

102 64 6 years ago

buaiscia.github.io

jiofih• 6 years ago

the famous property ‘children’, in React, corresponds to textContent in plain JS

That’s incorrect, if anything it corresponds to .childNodes. The textContent property is a getter that extracts text nodes only from all the nested children of an element.

hashkb2• 6 years ago

It's dangerous to think of any React prop as "corresponding" to a DOM property. Only exception I can think of is "dangerouslySetInnerHTML" which has "dangerous" in the name already.

Children can be a function, node, or array of nodes (or something else); and you need to know the API of the component you're using before you can really know anything about any prop.

sfvisser3• 6 years ago

It’s not dangerous, it’s just a sometimes sensical and sometimes somewhat wrong approximation.

Anyone who has ever used the browser DOM and starts using react will intuitively understand this from day one.

antris7• 6 years ago

I think part of the reason why React causes negative reaction towards perceived "Javascript fatigue" is that Facebook introduced too much at once.

There's no reason why JSX had to be included at the same time with React. There's no reason for it to provide classes, the whole bells and whistles.

They could have released just the Virtual DOM part of the library (which was the major innovation) and keep other parts of it to themselves or release them later. When React released with so many features at once, it looked on the surface like just another framework. In fact, people still call it a framework today, even though it isn't one and was never really meant to be one.

And the fact that React was released in a such a big package, it meant that people weren't eased into each of the concepts, one at a time. Suddenly you not only have to learn about Virtual DOM, but the class API, JSX at once. Some people even throw Redux at the junior programmer at the same time. Imagine having to learn so many concepts at once! No wonder it's hard to learn.

It's a pretty basic pedagogical concept. You have to introduce each concept in isolation and then build understanding of the whole from those parts. If you do not understand what the problem with vanilla DOM manipulation is, there's no rush to learn JSX and Redux!

I guess in the end I'm just glad you decided to play around with vanilla DOM manipulation and build from that, step by step. "Learn everything at once" doesn't work very well.

TheRealPomax2• 6 years ago

Given that they also released full and clear documentation _with_ a full and clear tutorial, I have to strongly disagree. They didn't release a library, they released a full framework and methodology that they had been using them selves already for writing huge web application UIs. Releasing it in tiny chunks would have made zero sense.

Heck, it speaks to how well written their docs and tutorials were, and how easy it was to pick up, that it became this popular in the first place. After all: React isn't actually a web technology, it's a traditional OOP framework that happens to use the browser as its UI layer. Nothing it does respects how the real webstack works, and makes it impossible to debug "as a web page".

Irrespective of how you feel about that part (because I love React as UI framework, but hate how we've told React devs that they're web dev, when they're very much not), the fact that it's stuck around and has become as popular as it now is speaks volumes to how much their release history was just fine.

antris7• 6 years ago

I didn't mean to say that React is bad, quite the opposite! It's a wonderful library and for good reason. But I've never used the OOP parts of it, because I like structuring my applications without a framework, customized to the domain I'm working on. Several mutable classes as a basic structure of an application is a no-go for me. Luckily, you could, can (and in my opinion should) use React without those parts, and the library works just fine as a VDOM engine.

Again, Facebook did an incredible job. I'm just commenting on why some people (not me) feel like React is "just another framework oh my god when does this stop". If they released the VDOM engine separately and the framework parts after that, people would understand that you can build your application in a way where you can pop out React and replace it with any other VDOM implementation. Most people don't seem to know this, and that's why they insist on calling it a framework.

Also, JSX caused so much confusion among people who were used to template engines. There was a huge opposition to React as a whole simply because JSX looked weird when people were explicitly taught to never mix JS with HTML. React didn't need JSX to work. For my first applications I didn't use it because I didn't want an extra compilation step, and the build/packaging tools back then were quite painful when compared to those of today. I could use React perfectly fine and it did its job in pure JS. JSX to me was just syntactic sugar, but it became a huge red herring to people who were introduced to React.

tshaddox2• 6 years ago

I get your point, but there’s still plenty of web-related concerns that don’t go away when you’re using React. Many aspects of accessibility, layout and styling, browser compatibility, performance, security, and more are largely unchanged whether you’re developing a React web app or a static HTML+CSS site.

Any time you encounter a website where the back button doesn’t work, or with a “link” that works when you click it but can’t be right-clicked to open in a new tab, that’s probably the work of a React dev who falsely believes they are not a web dev!

quxpar• 6 years ago

In order to build the first airplane, you need to introduce a lot of concepts at once. The Wright brothers needed to build a custom engine just to get the weight-to-power ratio they needed, on top of understanding spruce wood fabrication, wing aerodynamics, propeller design, etc etc.

If there was a logical midway point between the old jQuery-style paradigm and react, I suspect it would quite popular. However, all the react alternatives I've found make an equally large leap in terms of new concepts, because that's what makes the total development experience viable.

Edit: typo

dmitriid4• 6 years ago

There's no reason why JSX had to be included at the same time with React.

Why? JSX was one of the main reasons React became so popular. What would you have instead of JSX?

There's no reason for it to provide classes, the whole bells and whistles.

They didn't provide "classes whole bells and whistles". React came out before classes where even standardised in Javascript. And its original API of `React.createClass` was really no different from hundreds of similar APIs.

When React released with so many features at once

What? Which "so many features"? It released exactly that: a VDOM library with JSX and an API that was not much different from those on the market. That was the main reason it gained this much adoption: it was very simple, easy to understand and get into.

You have to introduce each concept in isolation and then build understanding of the whole from those parts.

That... That what React does. It introduces major new things with major new versions.

antris7• 6 years ago

Why? JSX was one of the main reasons React became so popular. What would you have instead of JSX?

JSX was also one of the main reasons why people opposed it at first. We were taught to never mix HTML and JS and put markup in a separate file. Of course separate template files as a concept were bad in the first place, but it served as a red herring for those learning. It "felt wrong" to many people who wanted to "just write Javascript". React works perfectly fine without JSX. I mean the syntactic sugar is nice, but the VDOM implementation was the breakthrough innovation that made React popular. You can have JSX if you want, but at the time of release, most people hated a new compilation step just for a bit of syntax comfort.

its original API of `React.createClass` was really no different from hundreds of similar APIs.

Yes, this is the API that I am talking about. There was never a need to combine state handling into the first virtual DOM engine. If there are hundreds of similar APIs, why create another one? Why not let the developer choose their own favourite Class implementation? Some people (such as myself) try to distance themselves from OOP as much as possible, so the class API was quite worthless.

ratww• 6 years ago

React could have used syntax similar to hyperscript by default, like:

  h('div', { class: 'm-3', onClick }, 'the text')

But I agree with you that it wouldn't be as popular.

mirthflat83• 6 years ago

This argument applies more to Angular 2 and them bundling rxjs with it. Learning React was a very pleasant experience

pier25• 6 years ago

I think the reason is rather that React forces you to write a lot of JS and learn many concepts vs something like Svelte.

I also feel it has become more complicated now with hooks which, ironically, were supposed to make things simpler.

nshung• 6 years ago

This. A lot of people get thrown into the top layer of the abstraction itself and then move down from there.

What instead should happens first is that these people should be shown the problems React or other frameworks for that matter are trying to solve. It is way more motivating to gradually move up the abstraction layer when learning.

Get the know the problem first and then find the solution to that problem. Not the other way around.

Octoth0rpe• 6 years ago

There's no reason for it to provide classes

I'm not sure I follow. ES classes predate react significantly IIRC. React may have been the first 'popular' library that made use of them extensively, but I don't think facebook should get credit for this one

There's no reason why JSX had to be included at the same time with React

Without jsx, the value of react code is _much much_ lower IMO. I don't think it had any chance of catching on without it.

Some people even throw Redux at the junior programmer at the same time.

Definitely agree that that is a mistake, but it also seems to be a mistake that people are long past. Not many people advocate redux these days, which I find unfortunate given how good redux toolkit makes it. That said, even without redux toolkit, it's definitely not something to throw at junior developers in their first week

...maybe week 3.

acemarke3• 6 years ago

ES classes predate react significantly IIRC

No, React was announced in May of 2013, and ES6 wasn't finalized until a couple years later.

it's definitely not something to throw at junior developers in their first week

FWIW, we specifically recommend that most folks should _not_ learn Redux until they're already comfortable with React. In fact, the new "Redux Essentials" [0] and "Redux Fundamentals" [1] core docs tutorials specifically say "we assume you know React already" as a prerequisite. (And yes, I really wish bootcamps didn't throw devs straight into Redux, but I understand why that happens. That's a large part of why I just rewrote our tutorials.)

Not many people advocate redux these days, which I find unfortunate given how good redux toolkit makes it.

Appreciate the kind words :)

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/tutorials/fundamentals/part-1-overview

efdee• 6 years ago

I'm not sure I follow. ES classes predate react significantly IIRC. Before React started supporting ES classes, they had React.createClass instead. I assume that is what the poster is referring to.

wilsonrocks• 6 years ago

I use react all day and the thought of doing it without JSX chills me

azangru• 6 years ago

I think part of the reason why React causes negative reaction towards perceived "Javascript fatigue" is that Facebook introduced too much at once.

This could be relevant if this conversation were taking place in 2014; but it’s 2020 now. Today, the negative reactions to React are caused by:

- it being on the heavier side of frameworks (given that some frameworks/libraries are below 10kB)

- its relative slowness in benchmarks (absent concurrent mode), and the ease with which an inexperienced programmer can make it slower and more resource-hungry than it should be

- its least compatibility with web components, compared to other frameworks

- bad practices that have arisen in the community around it (using react when there's no need for it; serving large html payloads with SSR containing a stringified populated redux state, etc.)

Aduket• 6 years ago

Your english is so articulate. iss this your native language, which i dont think so?

What is your native language and how did you get proficient in english? Thanks in advance.

k__• 6 years ago

If you want to learn React, but somehow the approach of most tutorials elude you. I wrote one from a different perspective.

https://github.com/kay-is/react-from-zero

remram2• 6 years ago

JavaScript fullstack developer

What does "fullstack" mean these days? Express and React (single language and two frameworks)?

richeyryan2• 6 years ago

Something like that yeah, maybe not React and maybe not Express but Javascript on the frontend and backend for sure.

Raphmedia• 6 years ago

Having wore that title before, it means "developer who is able to build a JavaScript application and bring it to production".

For me, this included doing UX/UI, the design, implementing web front-end (HTML, CSS, making sure it's responsive and optimized), the front-end business logic (Angular, React, Vue), setting up the server (typically the "back-end", either node.js or a more traditional approach like PHP), persisting to a database (like using MongoDB), managing APIs, etc.

I am not a fan of the title "full-stack" (to me, that's just what being a developer is) but you need to wear it in order to get the right job offers and salary.

For the longest time, front-end meant "HTML+CSS and a pinch of jQuery". So we need a title to break away from that trend.

remram2• 6 years ago

Yeah, it feels to me that it used to be HTML, CSS, JavaScript, a server language like PHP, and a SQL database. Now it's just JavaScript (with JSX), JavaScript (with express), and a JSON store (MongoDB, etc). The term "javascript fullstack" in the submitted article just gave me pause, you can be "fullstack" and really know a stack that's one thing deep.

archsurface• 6 years ago

Interested to see this because I'm neither a JavaScript nor frontend dev, but over the last two weeks have been gently learning React out of curiosity, applying it to a small personal project. The last time I used JavaScript was with Angular 1.x around 2013. Iirc the angular learning curve was negligible; React's is steeper, but I can't compare with modern Angular - seems it's up to 11.rc1. I get the impression React has mostly won the battle. I was wondering if maybe I should have tried Svelte instead, but React is the name I keep seeing, so figured that's where I'll peek (first?). I think the muddle I need to sort through at the moment is the old tutorials vs the new tutorials as I'm seeing multiple ways of doing things but don't yet know which are the new ways, the best practices, or the trade-offs with each.

agustif• 6 years ago

Good call on React vs Angular, Although Svelte is the newest cool kid in town, I'd rather go with Vue than Svelte.

Also NextJS is the best way to learn React IMHO, but it adds a lot of extra stuff so maybe wait until you need it

davidwparker2• 6 years ago

Besides the bigger ecosystem, curious as to why you'd go with Vue over Svelte?

I've used Vue for pet projects but Svelte a lot over the last 6-months and don't think I would reach for anything else but Svelte right now. (I'm sure that opinion will change over time, but between the speed of development, and the incredibly nice / fast applications I'm able to build, I've never felt more productive (on the frontend))

xxffgg5572• 6 years ago

Thinking react vs. angular as though they are trying to "win" some universal battle is just propagated by clickbait blogging. Enterprise + larger scale teams tend towards Angular, blog posts and hip projects tend towards react.

maclockard3• 6 years ago

I don't think this distinction is exactly correct. I've worked on some enterprise projects with larger scale teams that have used React. It offers a bit more control than Angular does in terms of what your frontend 'stack' is comprised of. This level of control can be appealing for large projects.

I kinda see a trend that projects started after x date tend to use React over Angular, but I am unsure of what x is or how universal this is.

nfRfqX5n• 6 years ago

yes, hip "projects" like as facebook, airbnb, walmart, nytimes, netflix use react

bluedevil2k2• 6 years ago

I disagree with this statement. The last 3 projects I've been on, all huge enterprise level projects, have all been React. Angular was purposefully not picked on the first project because it gets hard to maintain on huge projects, and the last 2 projects were moving existing Angular apps to React for that same reason.

ritchiea4• 6 years ago

The latest consensus is to avoid class components, use only functional components and use hooks to handle state & side effects. Ninety percent of React is building DOM, hitting APIs with an HTTP client and using useState + useEffect. And remembering that you must pass functions & data to child elements to communicate between or share logic across components.

poyu• 6 years ago

What’s the reason to avoid class components though? The official tutorial still uses it, though that could just be because it’s outdated?

bluedevil2k2• 6 years ago

Stay with React, don't go with the newest shiniest JS framework. React has a 3rd party solution for nearly everything so you can piece all these well-developed and well-tested modules together to make your app.

Others may suggest using Hooks right from the start, so I'll act as the counterpoint. Starting with Class components is easier to understand and less is happening magically. Almost everything can be accomplished using only 3 lifecycle methods - constructor, render() and componentDidMount. Once you're comfortable with how that all comes together, start to pick up Hooks

richeyryan2• 6 years ago

If you are doing asynchronous data fetching in your components, only using those three lifecycle methods will inevitably lead to bugs when your props or state update but your asynchronous call doesn't fire again because it was in componentDidMount. You need to use componentDidUpdate to trigger the call again when props or state update. Alternatively useEffect with the dependency array properly filled won't allow a stale state like that to occur.

csomar• 6 years ago

React is indeed very steep, but it is very productive if your application is complex enough. If you are going to use Static Site generation (react-static) and GraphQl (relay), then React quickly pays off.

My experience with Vuejs/React is that Vue is easy to start with and good enough. But once you need more integration with the ecosystem, you realize that React has better support.

dragonwriter2• 6 years ago

Iirc the angular learning curve was negligible; React's is steeper,

Almost everyone I've encountered has found React easier than Angular, though React is more prone to lead you into analysis paralysis with options, since it covers less OOTB and there are so many alternatives that interact with React for each of the other bits.

React Fundamentals: What I’m Learning

Related Stories