Thanks a lot, as a backend distributed systems person I have hard time understanding UI in general. I'm half way through your videos now, and for the first time I could grok what React is all about.
Thanks for this class. I'm just starting it. One question: How do I know when to do/start the curriculum? Will it be pointed out when I get far enough in the 'lecture' material?
From my point of view, React brings two important ideas to web app development:
1. The virtual DOM. When I'm writing jQuery-based code, I have to write both a component template and code that updates the DOM in response to input; when I'm writing code for a virtual DOM, the component template is sufficient to update the DOM and I don't have to write that extra code, so there are fewer chances for bugs to creep in.
2. HTML-like syntax embedded in Javascript (JSX). I didn't like this at first until I configured Sublime Text to highlight embedded HTML correctly. Embedded HTML has pros and cons, but I think it's a net positive.
React projects also typically include new tech like ES2015, webpack, hot code reloading, and Redux with its time-traveling debugger. You can build your own stack that uses a virtual DOM library, embedded HTML, ES2015, and so on, but it's helpful to start with a common stack that many people understand. That's why React is interesting.
Just a note paraphrasing a Medium post that I encountered that extends point 2: it's a lot more robust to work with a framework that essentially puts HTML into Javascript rather than many alternatives, which essentially do the reverse. Javascript is a lot more complex than HTML, and yet most of the alternative JS frameworks attempt to compress some version of its logic into templating.
What other platforms embed a subset of a language into the templating one? I've only seen this done in HTML. Even "back then" I opted to use pure PHP for templates rather that trying to use some comment magic based DSL that does little more than variable replacement and a for loop. The templates in Angular for example are a good example of what is wrong with stuffing code into templates rather than going the other way around.
Perhaps you could elaborate on the myriad of problems with data-binding the prior generation has encountered, and how they are fixed or exacerbated by React's solution?
And with number 2, this is subjective, should a template be responsible for rendering it's children (necessitating the need for for loops)? Should it handle filtering in the case of tabulated data, in a way that is consistent and re-usable, or should this be another layer sat between model/controller and the view?
- Combined with immutable state manager like Redux, it can dramatically simplify front end development.
I used to hate working on website frontends. Tangled webs of event handlers and dom mutation. React got rid of the mess and I once again enjoy working on the front end.
Let me provide a different viewpoint. React is important for ClojureScript developers for slightly different reasons. It is a well-maintained solution for quickly rendering component-based applications based on immutable data structures.
In other words, you can think of the user interface as a function of your app's state, where the state is neatly kept in one place, instead of smeared all over the code. And since ClojureScript has excellent immutable data structures, you get great performance right out of the box. Things that do not need to be re-rendered aren't.
So, when React arrived it fit like a well-designed glove. Suddenly one could easily create complex apps with few lines of code and great performance.
As a side note, there are some aspects of React that we don't care about. JSX is one: various lisp-like languages have been using vector/list syntax for HTML for years, so in ClojureScript you don't have to use a separate syntax or pre-process your files: your functions just return nested vectors with HTML elements. Much more natural.
1. Virtual DOM -- but this also includes DOM diffing, which makes it extremely efficient to re-render "the entire app" whenever a change happens (because you're not actually rendering it all but you largely don't have to know that).
2. JSX -- but unlike HTML this is just syntactic sugar for the underlying API. It may look like someone got HTML in your JS but it's really just syntax for nesting components and the rest is plain old JavaScript (compared to HTML templates where you have to learn a proprietary template language to do the same things you can already do in JS).
3. Unidirectional (one-way) data flow with pure components. This isn't enforced by React itself but if you stick to constructing your components this way (which companion libraries like Redux encourage you to do), your entire application becomes easier to reason about because you can think of your React code as one giant render function.
A lot of these concepts have appeared in other libraries and frameworks but prior to React we used to think that Angular 1's two way bindings were the holy grail (despite the countless complexities it brought in real applications).
At first I was really turned off by JSX. HTML in your JavaScript? Yuck! Then I migrated a 12k lines JS + 4k lines Angular templates to TypeScript. I didn't get any of the benefit of static typing in all of those html files. That was really upsetting to me. Getting compile time static safety on JSX components is awesome.
No one mentioned code sharing between server side and the client side! (There are other ways to achieve this other frameworks/libraries are catching up) If you have a node.js server you can use react for both server side rendering and client side rendering.. So that you get the SS rendering advantages like fast initial page load and SEO but also have a very dynamic web app after the initial render.
Does server side rendering actually provide a boost in SEO these days? I know google renders JS apps (would be pretty silly of them to create angular if they didn't) and indexes SPAs, but am unsure on the other search engines.
No. Google and Bing can index JS apps just fine, however many social sites still don't pull the title/descriptions from dynamically generated pages when you click the sharing button.
It fundamentally changes the way we think about frontend web development in a very positive way. It makes things more testable, reliable, fast, and easier to write. Combined with things like Redux we also get crazy features like time travel.
If your are optimizing for the development, you ar doing it wrong.
So sad to see years of effort on making web more accessible thrown out of the window.
How do react/angular/whatever sites work with assistive technologies like JAWS?
The first thing learning about these frameworks should be when not to use them.
I spend a lot of time worrying about this because I consult on accessibility issues, I an an accessibility advocate, and I am a low vision computer user.
Provided that developers use the proper HTML tags and ARIA roles, there shouldn't be any different issues here than with other JS libraries.
However, I want to stress that React, Ember, and Angular are amazing tools for apps, but if you are using them just to render static content, you're just inviting all kinds of accessibility issues that server-side rendering solved years ago. Web servers are optimized to serve static content quickly. Sending JSON to the client so the client can render HTML for a blog post or news article seems pretty wasteful, and again, invites accessibility issues that don't need to be there.
In addition to everyone else's replies, React Native is starting to take off as a next-generation Cordova: Javascript code using native APIs and native UI components rather than using JS and HTML in WebView using native APIs.
Tyler, I echo the parent's comments. I took your React course on Egghead back in August and it was great.
Question: I've been meaning to come back to it and re-watch the videos, but I'm concerned that the React ecosystem changes quickly and they may have become outdated. Can you comment? Do you have plans to update/re-record the videos as new versions of React/Redux/Flux etc. come out?
Thanks again for all the great work you're doing.
P.S. It would also be great if you could put timestamps on videos and courses, as it's difficult to see when they were added.
The react ecosystem does move really quickly. I think what's important to realize is that even though it moves quickly, if you learn the correct principles you'll just be stuck with minor API changes rather than architectural changes - which is a huge difference. I tried to approach the course from this point of view as well. Even if the API changes a little bit, the overarching methodology of building your UI will be the same. Someone who did the amazingly was Dan Abramov in is egghead series. Learn concepts, not libraries.
The videos have recently been updated to reflect changes in newer versions of React.
Segments have been replaced or spliced into the existing videos. It's noticeable (especially in some places) but it's certainly better than having outdated information.
Really can't decide to go ahead with an Angular approach (2.0) or use React. I know React is only for the view layer so what are people using with React to do stuff like api calls?
/components: These are all the JSX React components (the presentation layer) - so there are subfolders like "pages", "controls", etc.
/reducers: These are Redux reducers - they're the logic that handles all of the application state
/services: This is what your question was really about. We use basic ES6 modules for services, with methods like "fetchUser(id)" which use the new JS Fetch API behind the scenes. We then have redux-thunk and redux-promise middleware so we can easily offload state manipulation to these services without actually putting state logic in them.
I've set up a few React projects at this point and this always seems to keep a nice separation of logic. I'm never asking where data is coming from or where it's going. I think Redux has been the biggest difference maker when dealing with all of these parts.
It's no framework, but it's composed of well understood libraries, each with their own important function. You build the structure out yourself so you know exactly how it works, and the pattern will be very familiar to anyone who has used React before.
How does one create a reusable component (something I could publish on npm for example) for React + Redux? The component would have to define its own data expectations, so the actions and reducers would have to be defined by the component. How would you do this, given your folder structure (which I think is very common in Redux/React apps)?
Generally you don't actually use Redux in your component. Instead, you'd expose the action creators required by your component. Then the user has to make sure that the new state created from your actions gets back to your component via props. This is a common behaviour I've observed, anyway.
Yeah, this is an important question. I don't have answer for you and neither do the people in charge of the fetch API. It's an issue with promises not being cancelable. There's probably a reasonable argument that promises just aren't that great because you can only resolve or reject.
Personally I don't see a huge problem with either resolving or rejecting with a message about the cause of the result. Others see it differently but they haven't been able to make any progress on a major problem.
If you want to avoid this altogether there's no reason why you can't use a different library.
What about using observables? Unlike promises, they can be cancelled at any time.
Rxjs provides the observable data type. The extensions are functional reactive operators. There are operators used to retry, throttle, filter, debounce, etc.
Angular2's http module is already based on Rxjs observables for this exact reason.
I don't have an answer for you but I dislike that Fetch() doesn't currently have any support for progress events. So say good-bye to your file-upload progress bar!
I spent a month playing with the different libraries and settled on the following core modules for my frontend:
* redux: Keeps track of all the state (UI and domain) in a single object.
* immutable.js: Obviously for the immutable data structures which plays nicely within the React ecosystem. It also has a rich set of data structures that aren't found natively within JavaScript. For example I make heavy use of Records to simulate domain models.
* react-router: For routing within the application.
* superagent: For ajax calls.
* reselect: If using redux you'll cherry pick various parts of the state tree for your components. If any of the data used within components can be derived then reselect comes into play nicely.
It took longer than I had hoped but I finally have a strong set of libraries and project layout I'm happy and productive with.
Any good tutorials for CRUD-heavy redux apps? Do you dynamically create your action creators? Or did you write createWidget(), updateWidget(), retrieveWidget() and destroyWidget() manually per resource (and their 3 corresponding constants for REQUEST, SUCCESS and ERROR)?
And how do you ensure your detail components (WidgetDetail, or WidgetForm) have the widget loaded before displaying? asyncConnect?
I'm a visual person so perhaps seeing some code will help. I've gutted a CRUD heavy side project that shows how I lay things out and put it on Github [1]. I left out the back end folder so this repo isn't intended to work. The "users" and "journals" folders are the CRUD parts.
I prefer a domain folder structure versus splitting things by function. So instead of folders like "actions/userActions.js" and "reducers/userReducer.js" I'll do "users/actions.js" and "users/reducers.js".
I primarily use Django/Django Rest Framework as the back end so web-sockets are a pain right now. I'm looking forward to when Andrew Godwin's channel work gets into Django proper where socket.io would make a lot of sense. Unless I'm missing something and socket.io does ajax requests these days? I haven't used it in quite some time.
React seems to emphasize using regular javascript and existing NPM modules where possible. Superagent [1] seems to be a popular one, but you can find more on React's wiki [2].
If you start using a flux implementation like Redux, there are other interesting things you can do to handle api requests [3].
We're moving all our Angular code to React/Redux. Angular 2.0 seemed quite a bit more convoluted than React, even if it is saner than Angular 1.x.
Having simple and easy to create components is a major win. No one on my team ever liked or used directives much, as they were overly complicated.
Redux has been a huge win. In dev builds, every state change is output via a redux middleware, so it is easy to watch how state updates and transitions. In prod we plan on storing state updates and allowing them to be sent to support for trouble shooting. Even have plans for an overlay to allow support to step through those changes with a simple interface.
For me it comes down to what language are you more comfortable using. Plain old JavaScript with Babel ? React TypeScript ? Angular 2
Angular 2 is much more OO style GUI lib - if you've ever worked with stuff with WPF you'll recognize the patterns immediately - focus on DI, property bindings and attributes, class based design, etc. It really works well with TS and IDEs
React + TS is quirky to say the least - not just the base lib but the ecosystem - for example immutable.js is annoying to use with TS (creating typed records). It can be done but I'm not sure it's worth the effort.
But one huge consideration is that React has been "out there" for a while now - there's a ton of quality work available on top of it. In Angular 2 even the basics are in flux like animations and stuff like material design components are nowhere near in sight.
There's a touch more than views to consider, e.g. do you have to build or want a native mobile app? Angular 2.0 will be under heavy development whereas I think React has matured to the point where a lot of effort is going into ease of use and performance [1]. I also found the React tool chain (using webpack/babel5) very slightly more sane than grunt/gulp once my project grew beyond "Hello TODO". But the JS tooling is absolutely crazy no matter what platform is decided.
I'm using redux for API calls - I like the "single store" approach despite drawbacks vs. flux (or multiple stores).
I've only just started using React but I've been a Django developer for a few years. As I'm starting to use React, I'm still working with Django and Django-Rest-Framework for my backend. It's probably a little heavy weight but you could use something like Flask or whatever equivalent light weight Web framework is in your language of choice.
I think he's asking what to use on the front-end. The author of these tutorials (at least from what I've watched so far) uses axios: https://github.com/mzabriskie/axios
I'm a big Angular fan though I've done some React stuff as well. I think a reason to go with Angular 2 is the batteries-included approach (and TypeScript is cool once you get used to it, though certainly not required). With React you do end up having to hunt down libraries for everything beyond the view layer, which can mean a lot of random 3rd party libraries in various states of support. The flipside is the ecosystem is growing so could overcome those challenges and the architecture is simple and elegant. Honestly, I think ng2 is going to be really popular despite the backlash (and lack of HN representation) and so far the response I'm seeing is really positive once people dig in. I don't think you can go wrong with either though.
> which can mean a lot of random 3rd party libraries in various states of support
I think this aspect makes Angular feel more like the "Java EE" of the web world. You can throw an Angular developer at an existing Angular code base and I'm fairly certain he'll know exactly what goes where and how things are strung together without much digging around or documentation required. For enterprises this is a very good thing.
Here's a potentially dumb question about React: can it be used inside a client-side application that was written using Angular?
Part of my job involves customizing a commercial, closed-source web application that lets you build web forms. The application's front-end was written using Angular, but it lets you add your own custom JavaScript to add more functionality to forms, such as character counts, hiding/showing relevant fields based on conditions and auto-capitalization of user input. Basically, each form has its own JSFiddle-like section that gets published alongside the form.
We currently use native JS and JQuery for these customizations, usually within a monolithic document.ready block. The problem is that our code can get pretty complex, especially when hooking up multiple event handlers to the same elements. I've been thinking that React may be able to solve this problem, but I'm uncertain about using it alongside Angular, especially since I have no control over the latter.
Based on this description, would there be any advantages to trying to shoehorn React into our projects, or should we stick with native JS and JQuery?
Just started learning js etc. Was told Angularjs has everything loaded so it's easy for beginners, while React is better for the more experienced who knows how to pull various things together? is this true? if so is there a "React-stack" for me to start with?
It would probably be best to understand the fundamentals and then to figure out how components of the "stack" are wired together. This might help be a starting point - https://github.com/gaearon/react-makes-you-sad
Don't start with a full stack, it can be overwhelming. Start with a minimal toolkit and only add stuff when you actually run into pain points that it can solve. This guide is a good one:
Angular is harder for beginners because it has everything loaded. React has fewer consepts. When learning & for non-complex apps, you don't even need flux etc. extra stuff.
Serious question, and sorry(?) for bringing this up. But is everyone here really okay with reacts licencing?
Apart from stubbornly refusing to accept embedding html in js directly is a good idea (although I see the pros), licencing is the main reason I avoid this ecosystem altogether. Even though it has an outstanding community.
perhaps I'm making a deal out of nothing.
In any case will definitely take the course, im sure it will be as excellent as the others. Many thanks for your efforts Tyler.
What specifically about the licensing? This is an actual question, not advocacy. IIRC, Facebook had a provision that disallowed use of React for a ridiculously broad range of offenses with respect to any of FBs intellectual property but that they narrowed it considerably last year to a more reasonable: you aren't allowed to use any of our intellectual property in React if you dispute our ownership of that specific property.
I could be characterizing this incorrectly, or you could be referring to something I'm not aware of, so what specifically are you objecting to?
I don't know how much the course goes into this, but it might help you get started to keep in mind that it's not HTML in JS, it's xml-like JSX syntax as syntactic sugar for regular JS function calls.
It's no more "embedded HTML" than something like
$("<p>").text("lolwut").appendTo("body"), just written with a different syntax. Good luck!
We're using React/Redux to replace our Angular front end to MVC WebAPI. But we're also slowly replacing our MVC WebAPI backend to Node.js/Express. AD, LDAP, Tedious-Pooling, etc make it work perfectly in our MS environment.
I think I'm going to go through this this coming weekend, even if I am comfortable with React. Tyler is a great teacher and I could use help with the router and webpack.
Thanks for posting this! I've been dragging my feet about learning react for a week or so now and I think this will push me over the edge. Much appreciated.
