9 ms·
Show HN: Learn React fundamentals
- lucasch 8y agoVery 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 8y agoAh the ol' case-insensitive filesystem
- francislavoie 8y agoOoh, 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 8y agoIm about to do the opposite switch. Any chance you have any good resources for someone new to vue
- ggregoire 8y agoWhy not just read the doc?
- BigJono 8y agoNo 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.
- ivanhoe 8y agoOh, you mean you have to invest some time to learn it to be able to use it?
- BigJono 8y agoI know you're being a smartass, but yes, actually. Given two tools that do the exact same thing where one requires more specialised knowledge to use than the other, you'd be an idiot to choose the more complex one without receiving any compensation.
- untog 8y agoIn fairness, you're comparing a situation where you already know the specialised knowledge to one where you do not. Higher order components are simple in React precisely because you know the framework inside out and you know what a JSX transform does, internally, sight unseen. That's not particularly intuitive! It just feels that way because you know it well. > There's always a 'Vue' way to do it, rather than a 'Javascript' way to do it. I mean, come on. There's a 'React' way to do almost everything too. Want to create an element? No document.createElement for you, you'll be wanting to import ReactDOM, make a class that extends Component (or make a stateless component via a function. Also not intuitive!), then render that component into the DOM.
- ng12 8y ago> No document.createElement for you, you'll be wanting to import ReactDOM, make a class that extends Component (or make a stateless component via a function. Also not intuitive!), then render that component into the DOM. Yeah but you just described the entire framework. What he's driving at is that React had a very small API surface area, Vue has a much larger one.
- ivanhoe 8y agoIt all depends where you come from, for instance if you've ever used Angular, you'll pick up Vue's syntax in one afternoon, it's super simple transition. Also to any backend programmers it will probably feel more familiar than JSX. And I also don't think it's more complex, once you learn to add those few special attributes to html. I work in React mostly but to me Vue's templates are way cleaner than JSX when it comes to writing boolean conditions, you have closing tags instead of ))})}})}} mess and any editor will know to highlight them for you, you don't have to use external libs like classnames to compose css classes elegantly, it's already built in, you can pack js and css in one component without any external libs and hacks. Of course, I'm not saying you're wrong for liking JSX better, it's simply a matter of personal taste and depends heavily on your background.
- tomglynch 8y agoInstead you two should just swap jobs
- francislavoie 8y agoAhahaha! I mainly do PHP though, so it probably wouldn't be a good fit. I mainly just fill the gaps in frontend tasks occasionally when needed (but used to do a lot more frontend at my previous job).
- wiennat 8y agoVue, Vuex, and Vue-router official document are good enough. Many concepts in Vue are similar or quite simple compared to what you have to know in React. However, I find that Vuex is a little bit more verbose than Redux. You might it troublesome at first but will be better after you are familiar with it. Agree with other comments that Vue and its companion libraries have much larger API surfaces and have a lot of magic while React's advance techniques can be built upon few basic fundamentals so you need more time to remember those. But I feel that most of APIs are practical solutions to problems you need to fix by yourself in React.
- mlsarecmg 8y agoHere's something that Swizec Teller wrote after having to use it on a project: https://medium.com/@swizec/some-thoughts-on-vue-after-deploying-my-first-production-app-e7f3be73ce43 https://medium.com/@swizec/some-thoughts-on-vue-after-deploy... In essence, many things you take for granted do become harder because Vue is modelled after older templating frameworks like Angular, so you're jumping right into DI again and scope separation. It makes it less flexible and simple compared to React. My biggest gripe with it was that for many problems the basic knowledge you have isn't enough, you need Vue-specific solutions (remember the "Angular-way"?). After a while it gets easier.
- AngeloAnolin 8y agoSomeone mentioned here the book Full Stack React [0]. The same team also made a great book for Vue: Fullstack Vue [1] [0] https://www.fullstackreact.com/ https://www.fullstackreact.com/ [1] https://www.fullstack.io/vue/ https://www.fullstack.io/vue/
- deleted 8y ago[deleted]
- jamestimmins 8y agoThis looks like a lot of fun. I'm currently learning React so I'm excited to dive into this. Thanks for sharing!
- tyroprogrammer 8y agoNo problem! Just remember to create PR/drop suggestions (if any) after you are done with the tutorial.
- acemarke 8y agoFolks 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-learn-react/ http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea... [1] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [2] https://www.reactiflux.com https://www.reactiflux.com
- matchbok 8y agoPlease 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 8y agoI 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.
- tr33house 8y agoYou seem to imply that it's always horrible ux. Care to elaborate?
- kkarakk 8y agoyes that's why teachers keep a giant printout of the textbook next to the whiteboard. except wait, students get to choose whether to look at the textbook open in front of them.quite the flaw in your logic. Teachers do need everything in front of them because they have to choose what resource is best to explain, students usually need to focus on one thing and learn it well.
- paul7986 8y agoIm 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 8y agoReally 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 8y agoThanks 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.
- ehnto 8y agoIt's because browsers are the target deployment environment, and browsers move pretty slowly (although a lot faster in recent years). So to use modern language features (such as ES6 or Typescript) you have to transpile back to older JS. For many projects, I don't personally think it's worth the tradeoff of tooling setup and dependencies, so I won't use it in those cases. But for decently complex projects it is nice to use modern language features.
- hobofan 8y ago> 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).
- victor106 8y agoThis 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.
- azmany 8y agoThanks for sharing! This looks great
- philliphaydon 8y agoIf a project like this uses Yarn? Is it possible to use it without Yarn?
- jbfm 8y agoYes, just replace yarn start with npm run start
- _eric 8y ago`npm start` works aswell
- asutekku 8y agoIt’s the first thing addressed in FAQ
- philliphaydon 8y agoAhhh i read the 'follow the tutorial' bit and then came back here to comment, I didn't see the FAQ at the bottom.
- alfonsodev 8y agoyes, 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 8y ago<3 thanks.
- ndstephens 8y ago
- pankajk1 8y agoJust 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 8y agoGlad it helped and thanks for the suggestions - will take them into account!
- mettamage 8y agoMy 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 8y agoThe 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 8y agoI 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.
- thegeomaster 8y agoOne 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 8y agoSeems a little light on tests?
- mstade 8y agoHey, that's a great project – thanks for sharing!
- nickjj 8y ago100% agreed. Personally when learning a new framework, nothing beats seeing real code that serves a real use case. That's why all of my courses are based on real world examples. For example in https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/ we build a SAAS app with Flask and cover 50+ web dev concepts along the way. Users, accepting payments, invoicing, testing, etc..
- deleted 8y ago[deleted]
- wpmoradi 8y agoMost of my work is changing existing react code, this tutorial is great to see a bigger picture. props to you man ;)
- tyroprogrammer 8y agoGlad it helped.
- deleted 8y ago[deleted]
- chocks 8y agothis looks awesome! will give it a try. Thanks for creating this :)
- jordache 8y agowith package-lock, there are very few reason to use yarn over npm