
Show HN: Learn React fundamentals - tyroprogrammer
https://github.com/tyroprogrammer/learn-react-app
======
victor106
This looks great.

One of the best books I learnt React when I was starting out was from
[https://www.fullstackreact.com](https://www.fullstackreact.com)

I loved the way they broke down concepts and build one on top of the other.

------
acemarke
Folks might also be interested in my suggested list of resources for learning
React [0] and my React/Redux links list [1].

Also, come by the Reactiflux chat channels on Discord! [2] Always plenty of
people hanging out happy to answer questions.

[0] [http://blog.isquaredsoftware.com/2017/12/blogged-answers-
lea...](http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-react/)

[1] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

[2] [https://www.reactiflux.com](https://www.reactiflux.com)

------
jamestimmins
This looks like a lot of fun. I'm currently learning React so I'm excited to
dive into this. Thanks for sharing!

~~~
tyroprogrammer
No problem! Just remember to create PR/drop suggestions (if any) after you are
done with the tutorial.

------
wpmoradi
Most of my work is changing existing react code, this tutorial is great to see
a bigger picture. props to you man ;)

~~~
tyroprogrammer
Glad it helped.

------
chocks
this looks awesome! will give it a try. Thanks for creating this :)

------
lucasch
Very cool website. I've been trying to learn react lately and this seems like
an easy to use approach.

Heads up though: The first exercise seems to have lowercase/uppercase issue
where it expects 01-HelloWorld-solution.js but the file is actually named
01-helloWorld-solution.js. The same is true for the exercise itself
01-helloWorld.js ==> 01-HelloWorld.js.

Once you rename them it seems to work just fine!

~~~
secondstring
Ah the ol' case-insensitive filesystem

------
pankajk1
Just completed the tutorial. Nice exposition. Most of my work with React so
far had been modifying existing programs to make small changes in behavior.
The tutorial helped to form an overall picture.

What I liked: 1\. No grand philosophical statements about functional
programming paradigm or how awesome is React. (Most tutorials I have seen
spend more ink on these than on the real stuff) 2\. Easy way to install the
tutorial and validate exercises. 3\. Using React to teach React (the tutorial
is a React program but this aspect is not emphasized).

My suggestions to the Author: 1\. Leverage the fact that the tutorial itself
is a React program to go one level deeper. This probably would require its own
set of pages, each page emphasizing a different aspect such as Router and
other components. It took me a while to appreciate that Components are not
only for visual elements but they can also change behavior (example: Router).
2\. Use HMR to load only the Solution component so that only that part of the
page changes when the reader saves his edits. This will be a great showcase of
React's power of applying only delta changes to a page. 3\. This is a minor
nit: the color of numbers in the tutorial is too close to the color of the
background. Please use a different color.

~~~
tyroprogrammer
Glad it helped and thanks for the suggestions - will take them into account!

------
azmany
Thanks for sharing! This looks great

------
jordache
with package-lock, there are very few reason to use yarn over npm

------
mettamage
My way of how I learned React:

1\. Read the book [1] and type every code of his by hand and create a snippet
folder. Stop reading this book around two thirds in when he gets too deep on
caching and does not much with React.

2\. Read the Facebook Hello World tutorial, type everything by hand again and
understand it. Add it to your snippet folder.

3\. Try to make your own to do list++ app. You can use Google and
Stackoverflow but try to remember things first and don't jump back to the
Facebook tutorial and the Road to React book. The app I created was a React
app in which you could submit your bookmarks and give it a star rating up to 5
stars, it's a feature that I'd _really like_ in Chrome. Add it to your snippet
folder

4\. Get started with a real project.

In this approach, I think this website would be a good addition or replacement
for step 2.

Expectations and goals for each step:

1\. Gives you context and insight (you care about context).

2\. Gives you insight while having the context.

3\. Transfers this knowledge 'to your fingers' a bit, you just feel the idioms
in your fingers a bit more when you're done. I.e. practical experience

4\. Deepens the practical experience enough for one to say "I am able to
program with React."

[1] [https://roadtoreact.com/](https://roadtoreact.com/)

[2] [https://reactjs.org/docs/hello-
world.html](https://reactjs.org/docs/hello-world.html)

~~~
projectramo
The way I usually do is to work backwords.

Start with a project "real" or easy, learn each step as I need it.

A lot of this is copying and pasting code and then modifying it, and then go
back and learn what the "basics" are.

More like 3..1...4...2

So in order to do 3, I will have to look at some of the hello world examples
(I know nothing at this point). When I am through I may modify it to make it
more ambitious, and then might need another resources. (usually stack
overflow).

ymmv

~~~
mettamage
I wonder if your step 2 at the end and my step 2 are the same. Would you
really read the Facebook tutorial after having done a real project? Doing it
that way seems like an after thought.

I get 3, 1, 4 though. You first dive in practically, then learn the theory and
then immediately start on a real project.

I am trying your approach with regards to 2D and 3D plotting on a canvas
element.

------
matchbok
Please get rid of the hidden menu + hamburger button. It's horrible, horrible
UX. Screens are wide enough to show a menu. Esp for teaching, you want all the
options and tools freely available.

~~~
nonrecursive
I think that's debatable. Hiding the content allows the learned to focus on
the content at hand. If the user prefers to always be looking at a TOC, they
still have that option.

Or maybe it makes sense to show the TOC by default, with the option to hide
it. Either way, I'm curious to hear more about your reasoning for why it's so
horrible.

------
philliphaydon
If a project like this uses Yarn? Is it possible to use it without Yarn?

~~~
alfonsodev
yes, it is posible, in practice the only difference is that some commands like
build, eject, build:markdown you'll have to add the word run.

`yarn build` equals `npm run build`

`yarn eject` equals `npm run eject`

and so on ... except install, start and test which work without run.

`npm install`

`npm start`

`npm test`

There is another difference which is about the .lock file, you can delete yarn
yarn.lock and keep the package-lock.json that will be generated after you run
npm install.

To understand how this affect you need to understand semver and how the lock
file works.

~~~
philliphaydon
<3 thanks.

------
thegeomaster
One thing I find indispensable when trying to navigate the crazy amount of
JavaScript frameworks these days is the RealWorld demo app [1]. It's a spec
for an application that is more complex than the standard todo app, and there
are implementations of that same app in dozens of frontend stacks. I usually
take a look at the code when I'm not sure how to structure something in my
code, because the problem was often encountered there and has a sensible
solution. By contrast, when I Google around for some design/architecture
dilemma when writing frontend JavaScript, the quality of content is terrible
and I usually find dozens of alternative solutions, often by people who've
obviously used none of them.

[1]:
[https://github.com/gothinkster/realworld](https://github.com/gothinkster/realworld)

~~~
switch007
Seems a little light on tests?

~~~
dentemple
So "real world" is an apt description, huh?

------
paul7986
Im fairly new to Angular 2 and above and wonder why everytime I want to test a
new piece of code does the project have to re-build itself. The rebuild takes
almost up to five minutes.

I know this is a post about React (which doesn't it run on Node too), but as
framework noob wondering why development has become so arduous vs. build it
locally & refresh the page.

Also, the npm module stuff .. i mean some rando in the world updates their
module and boom breaks the build for millions everywhere. WHAT? How is this
efficient and better then prior to all these frameworks that run on Node?

~~~
making3
Really depends on how you are building. If you're building a decent sized
project with Webpack and production mode (with minifier stuff), then it might
take a few minutes. Dev mode, shouldn't take a ton of time.

~~~
paul7986
Thanks so based on your comment and the other this is modern web development
and we accept it.

Building sites in html/css & JavaScript was a better development UX and
faster. This constant compiling even quickly is silly and a fourth of my day
is spent doing so.

~~~
hobofan
> Building sites in html/css & JavaScript was

This is still building sites in HTML/CSS & JS. You can even use React without
Webpack if you want to if you are okay with a different syntax, and want to
avoid transpiling at all cost.

If you want to have quick iteration cycles for tweaking CSS, you still cleanly
separate your CSS from the rest of your component and use something like
Storybook. The CSS changes will be detected and autoreloaded near instantly
(sub-second).

But yeah, if you want to build robust interactive elements with syntactic
sugar, you will have to bite the bullet and accept a bit slower refresh time
(2-5 seconds with HMR on most projects I worked on).

------
francislavoie
Ooh, perfect timing. I'm switching to a team that uses React rather than Vue
(which I have more experience with). This'll definitely come in handy.

~~~
matuszeg
Im about to do the opposite switch. Any chance you have any good resources for
someone new to vue

~~~
BigJono
No resources, but I do have some advice: Don't do it (if it can be helped). I
made the switch and jumped into a Vue project at work, and I'm hating every
second of it.

Vue is for noobs and back-end developers that don't know any better. There's
no reason whatsoever to use it after you're familiar with React. Don't buy
into the hype. There's lots of things that are intuitive or easy to learn in
React, and have to be researched and memorised in Vue. Being a 'Vue' dev is a
constant exercise in rote memorisation and remembering how things behave in
certain edge cases.

Let me throw out an example I ran into 2 hours ago. I could do this basically
any day of the past 6 months and give you a different example.

Say you need to render a component dynamically based on some data. Maybe you
have the name of the component in a string (i.e it's come from a back-end etc)
and know the scope it lies in, or maybe you're passed a component as a prop
(you see this pattern all the time in higher order components in React, i.e
'(Component) => <Component />')

In React, you can simply do the above. If you've been programming in React for
a while you probably intuitively _know_ that you can just do (Component) =>
<Component />, why? Because the JSX transform is trivial, and you can do it in
your head.

When you render a component in React, you know that the '<Foo />' transpiles
down to React.createElement(Foo). It doesn't matter how Foo enters the scope,
whether it's imported at the top of the file (and therefore closured into your
function) or comes in as a prop, it'll just work. As long as you're familiar
with the Javascript language, you'll _know_ this just works.

In Vue, it's not that simple. Because Vue components are all in this complex
templating language, you need to look up how to do even slightly advanced
things like this. There's always a 'Vue' way to do it, rather than a
'Javascript' way to do it. Or, as in this case, there's a "refactor your
entire component to be a render function" way to do it, almost like an
'escape' to using actual JS, because the Vue templating language just isn't
good enough to handle what you want it to do.

And god help you when you need to try and figure out the Vue way of doing
something via Google instead of having an expert mentor on your team to help.
Forget the official docs, they're garbage. And Vue (as well as React, to be
fair) has the same problem PHP had 15 years ago, squillions of noobs have just
flooded into the ecosystem and resources like Stack Overflow, chat rooms etc
are swarming with "slightly experienced noobs" trying to help people a little
bit newer than themselves. The quality of online resources is shockingly low.
Even if you're an experienced front-end dev and know all the terminology and
how to phrase your questions and search queries, there's no guarantee everyone
else does, so you'll have to wade through 50 nonsensical answers to every
problem you might run into. It's infuriating, inefficient, and soul sucking.

And, you know what, just in general I'd never recommend anyone switch front-
end libraries unless you have literally nothing else to do. As far as your
personal learning and career progression goes, it's always best to learn how
to do something new. Failing that, it's sometimes good to learn a different
way of doing something. But the absolute worst thing you can do is learn a
different representation of the _same_ way of doing the _same_ thing. Vue and
React are the exact same shit. You're better off learning the inner workings
of one of them (try building your own, it's fun!) so you can bring that
knowledge to the next trendy crap that comes along, rather than trying to
learn all the trendy crap.

~~~
_mrmnmly
I really try to convince myself that this is not a troll comment.

But I can't.

[edit]

Since somebody downvoted my previous form of comment (probably because of lack
of constructive opinion) I'll fix it now:

Calling other programmers noobs doesn't make you a better person by any means.

On one side you're saying that Vue.js is that easy to learn so there's lots of
noobs using it, but on the other side you're saying that you need constantly
google/look into to docs for help.

Vue documentation is the best introduction to the tool I've ever encountered.
Same for the rest of the docs for the Vue's ecosystem - they're written in
consistent form, so you can just simply 'jump in' and learn progressively.
Even templating language looks like already familiar good old HTML. I was
prepared to build production-ready application after a week of messing around
with Vue & its documentation.

I can't tell same much good words about React, since after spending a month
with it I couldn't figure out how to solve some basic edge-cases (like finding
proper way to style components - are you kidding me, React is like 3+ years
old, used by thousands of developers and people are still arguing about proper
way of styling its components? In Vue you just put it into `<style>` block of
Single File Component, or serve generic ones in the global stylesheet file and
that's it, simple as that.)

But I think it's just a matter of personal preferences - Vue just suit me
better, while React doesn't. I don't like react personally - but I do respect
the people who created it and these who uses it on daily basis. Period.

Every developer can choose hers/his tools that suits best, but calling someone
because of that a noob is... just unprofessional.

I will take an opportunity and share here a link to one of my notes about the
related topic: 'If Vue.js is worth a shot?': [https://lukaszkups.net/notes/is-
vuejs-worth-a-shot/](https://lukaszkups.net/notes/is-vuejs-worth-a-shot/)

enjoy ;)

~~~
mlsarecmg
You style components in React like you always did before. That's the whole
thing about it, it never changes what you know. ... Unless you decide using a
more modern approach like styled-components et al.

