Edit: Awesome replies, thank you!
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.
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.
It's not a 'new' complaint about React, it's been said plenty of times, go do your own research.
Can you share your sublime settings or syntax configuration you are using?
Also data-binding brings its own myriad of problems that older programmers will know about from the days of desktop programming.
And 2 just sounds like a violation of the rule we've all learnt not to mix presentation and code.
So they're not reasons why React is interesting.
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.
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).
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).
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.
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.
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.
Dan Abramov did a free egghead series on Redux, which also provides a subtle intro into React: https://egghead.io/series/getting-started-with-redux
I think the genius thing about Dan's series is that he tricks you into learning how to use Redux by "re-inventing" it.
Read this: http://reactfordesigners.com/labs/reactjs-introduction-for-p...
If this article does not convince you, React is not for you and that's OK.
I fiddled with it a bit but I couldn't get any of the examples working. <shrug>
/actions: Flux action creators
/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.
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.
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.
* redux: Keeps track of all the state (UI and domain) in a single object.
* 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.
And how do you ensure your detail components (WidgetDetail, or WidgetForm) have the widget loaded before displaying? asyncConnect?
Thanks in advance for any pointers!
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".
Ping me on github if you have any more questions.
If you start using a flux implementation like Redux, there are other interesting things you can do to handle api requests .
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.
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.
I'm using redux for API calls - I like the "single store" approach despite drawbacks vs. flux (or multiple stores).
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 is why Relay matters:
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?
I had the chance to talk with him after a local JS meetup and he was super nice. Can't recommend his stuff more.
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.
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?
It's no more "embedded HTML" than something like
$("<p>").text("lolwut").appendTo("body"), just written with a different syntax. Good luck!
Opera on Android, cookies enabled; Adblock Plus enabled or disabled, no changes.
Edit: I checked with Firefox and Opera on Ubuntu and it works.
document.getElementsByTagName('video').playbackRate = 1.2;
Thanks for making this free!