Learn React by building a web app(udilia.com)
udilia.com
Learn React by building a web app
https://udilia.com/courses/learn-react-by-building-a-web-app
106 コメント
If one enjoys learning by video I can recommend "The Net Ninja" on YouTube. He has a series on React.js (as well as many other languages and frameworks): https://www.youtube.com/playlist?list=PL4cUxeGkcC9i0_2FF-Wht...
I fear that by the time I'm good enough at react, another library will come out
Eh, React is 5 years old. I've been writing it professionally for 3. I'm not worried.
And honestly -- React doesn't have the same pain points jQuery/Backbone/Angular1 did where I couldn't wait to move on after 6 months. We'd have to see an absolutely massive paradigm shift before I'd regret writing my apps in React.
And honestly -- React doesn't have the same pain points jQuery/Backbone/Angular1 did where I couldn't wait to move on after 6 months. We'd have to see an absolutely massive paradigm shift before I'd regret writing my apps in React.
I would argue React will be around a while for two reasons:
- The core language has gotten a lot better with ES5+ features. Async, fetch promises, etc., are all now built-ins on modern browsers, and have learned lessons from the pain points the initial implementations in libraries like jQuery.
- React itself is only a view layer with minimal concern about the form of your data -- you can use an array of other libraries on top of it to help with shared states, network requests, etc.
Will someone come along and do a view layer better than React? Probably. Will it be as big of a leap as what we've seen over the past few years with ES5/6/7 & React? I don't think so.
- The core language has gotten a lot better with ES5+ features. Async, fetch promises, etc., are all now built-ins on modern browsers, and have learned lessons from the pain points the initial implementations in libraries like jQuery.
- React itself is only a view layer with minimal concern about the form of your data -- you can use an array of other libraries on top of it to help with shared states, network requests, etc.
Will someone come along and do a view layer better than React? Probably. Will it be as big of a leap as what we've seen over the past few years with ES5/6/7 & React? I don't think so.
I feel this way about React but Redux seems awkward and worthy of replacement. Am I in the minority on this?
No, you're probably in the majority. The problem isn't really the core concept of Redux, but needing to integrate the whole ecosystem around it - thunks, sagas, selector library, various other middleware.
Standard redux is just too low-level.
Take a look at Mobx State Tree https://github.com/mobxjs/mobx-state-tree
Standard redux is just too low-level.
Take a look at Mobx State Tree https://github.com/mobxjs/mobx-state-tree
There are tons of options for State Management before you even need Redux.
Check out:
Context API: https://reactjs.org/docs/context.html
Unstated: https://github.com/jamiebuilds/unstated
MobX: https://github.com/mobxjs/mobx
Context API: https://reactjs.org/docs/context.html
Unstated: https://github.com/jamiebuilds/unstated
MobX: https://github.com/mobxjs/mobx
Meiosis is a simple state pattern, a very elegant approach to handling state: http://meiosis.js.org
You are not alone. After trying out GraphQL with Apollo, going back to Redux is painful.
I'm a Redux maintainer. Any particular pain points you're concerned about?
Not OP, but my day to day job is helping teams with their migration onto React (often for big sites you've used or have at least heard of). Here goes, although these probably aren't anything new to you:
– As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extremely painful. Everyone just uses Redux directly in their apps. As a result, adopting Redux on every team I've ever been on has been a painful process of figuring out how to fill in the blanks that Redux left out. Like how to handle async actions and side effects, how to name action creators, where to put connect()ed components, etc. And the result never feels great.
– Related to the above: it's extremely telling that I can't name a single library of reusable Redux actions/reducers/etc. Despite attempts to define things like "ducks", and there being hundreds/thousands of reusable React components published, there are none for Redux that anyone has ever paid any attention to. Because of the batteries-not-included philosophy, you pretty much just can't share your Redux code, because different apps might be building on vanilla Redux in too disparate a fashion with whatever middleware they chose. That's why I'm expecting the new Context API to displace a fair amount of Redux usage: because publishing reusable Context libraries is going to be brain-dead simple compared to reusable Redux.
– Developers just don't get what they should connect() and how to design their components, and Redux doesn't really offer them much guidance. As an example, every single day I have to mention in code reviews that something like a "loadProducts" prop does not make any sense on something like a "SearchButton" component, just because our Redux action happens to be named "loadProducts" – an "onClick" prop that just happens to be mapped to "loadProducts" in connect() makes much more sense. But devs are lazy and just end up giving components a bad design with a bunch of props that wouldn't make sense if Redux were not involved. Most of my code reviews contain the words "design your component's API without even thinking about Redux yet!"
There are more, but those are the main issues. btw, thanks for all the hard work you do!
– As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extremely painful. Everyone just uses Redux directly in their apps. As a result, adopting Redux on every team I've ever been on has been a painful process of figuring out how to fill in the blanks that Redux left out. Like how to handle async actions and side effects, how to name action creators, where to put connect()ed components, etc. And the result never feels great.
– Related to the above: it's extremely telling that I can't name a single library of reusable Redux actions/reducers/etc. Despite attempts to define things like "ducks", and there being hundreds/thousands of reusable React components published, there are none for Redux that anyone has ever paid any attention to. Because of the batteries-not-included philosophy, you pretty much just can't share your Redux code, because different apps might be building on vanilla Redux in too disparate a fashion with whatever middleware they chose. That's why I'm expecting the new Context API to displace a fair amount of Redux usage: because publishing reusable Context libraries is going to be brain-dead simple compared to reusable Redux.
– Developers just don't get what they should connect() and how to design their components, and Redux doesn't really offer them much guidance. As an example, every single day I have to mention in code reviews that something like a "loadProducts" prop does not make any sense on something like a "SearchButton" component, just because our Redux action happens to be named "loadProducts" – an "onClick" prop that just happens to be mapped to "loadProducts" in connect() makes much more sense. But devs are lazy and just end up giving components a bad design with a bunch of props that wouldn't make sense if Redux were not involved. Most of my code reviews contain the words "design your component's API without even thinking about Redux yet!"
There are more, but those are the main issues. btw, thanks for all the hard work you do!
I'll be honest and say that a lot of those concerns seem like things that Redux couldn't possibly have any solutions for. How can the core library tell you "what to name action creators" or "where to put connected components"? Those are style guide / app architecture concerns that are going to be specific to each team.
FWIW, there _are_ a lot of chunks of reusable Redux-based logic out there (which I have listed in my Redux addons catalog [0]), but I'd agree that there does tend to be enough variation in people's use of Redux that sharing larger chunks can be difficult. I've seen quite a few experiments with various forms of Redux "modules", but yeah, none of them have fully taken off. There _are_ several very interesting higher-level wrappers around Redux that look like they offer potential solutions to the reuse / structure question, like Kea, Rematch, and redux-bundler.
While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case. If you've got suggestions for improving the docs, please file an issue, or even better, a PR, and we can work to get something in.
FWIW, there _are_ a lot of chunks of reusable Redux-based logic out there (which I have listed in my Redux addons catalog [0]), but I'd agree that there does tend to be enough variation in people's use of Redux that sharing larger chunks can be difficult. I've seen quite a few experiments with various forms of Redux "modules", but yeah, none of them have fully taken off. There _are_ several very interesting higher-level wrappers around Redux that look like they offer potential solutions to the reuse / structure question, like Kea, Rematch, and redux-bundler.
While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case. If you've got suggestions for improving the docs, please file an issue, or even better, a PR, and we can work to get something in.
> Those are style guide / app architecture concerns that are going to be specific to each team.
Exactly, but it's Redux's fault that it actively adds like 5 new styleguide/app architecture concerns to worry about in your project! That is a bad thing about its fundamental design.
For crying out loud, just put redux-thunk back in the core library. Nobody doesn't have async actions! One less thing to make a decision about.
> While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case.
I find that response pretty obtuse. I just told you what I told my developers in their code reviews, how about some language like that? Developers don't realize that connect() is just dependency injection for props, and those props should at least make sense from a dumb-component standpoint before Redux is involved.
Or how about including a render-prop version of connect in the library, so developers don't go making a bunch of useless props in the first place? The HOC version is what is leading them towards poor design decisions.
If your library is too easy for average devs to use poorly and my biggest headache during code reviews, to me that points to some issue with the library. This is why there is often "backlash" type sentiments around Redux being so popular.
Exactly, but it's Redux's fault that it actively adds like 5 new styleguide/app architecture concerns to worry about in your project! That is a bad thing about its fundamental design.
For crying out loud, just put redux-thunk back in the core library. Nobody doesn't have async actions! One less thing to make a decision about.
> While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case.
I find that response pretty obtuse. I just told you what I told my developers in their code reviews, how about some language like that? Developers don't realize that connect() is just dependency injection for props, and those props should at least make sense from a dumb-component standpoint before Redux is involved.
Or how about including a render-prop version of connect in the library, so developers don't go making a bunch of useless props in the first place? The HOC version is what is leading them towards poor design decisions.
If your library is too easy for average devs to use poorly and my biggest headache during code reviews, to me that points to some issue with the library. This is why there is often "backlash" type sentiments around Redux being so popular.
FWIW, I've put together a small "starter kit" lib that's intended to simplify some of the process around setting up a Redux store [0] . We do include redux-thunk by default there, as well as Immer for simplifying immutable updates in reducers. It's still a personal-scoped package atm, but longer-term we'd like to make it an official Redux-branded addon.
I'm serious about the request for a docs PR. I'll agree that our docs are currently a bit weak on "real-world" app architecture instructions. If you feel there's specific advice that should be in there, _please_ file a PR! I'm already swamped with other things on my task list, and simply don't have time to add major new sections to the docs myself right now. I keep begging the community for help improving the docs so we can make things better for everyone, and I have a bunch of open issues tagged "docs" I've been trying to get help with, yet we get almost zero actual meaningful contributions.
I'm not sure how HOCs vs render props "leads people to make poor design decisions".
The Redux team's main focus in the near future is figuring out how to update React-Redux to better work with the upcoming async React rendering capabilities [1]. We've got a couple open PRs atm, one that's trying to fix the "strict mode" warnings [2], and one I did a few weeks ago that experiments with using the new context API for better compatibility [3]. The immediate goal is to keep the public API the same to provide basic compatibility with async React behavior, but longer-term, we may have to rethink the API to fully take advantage of what React can do. We aren't planning to add a render props API right now, but that could be on the table for a v6 API change in the future.
Again, right now there's two primary maintainers: myself, and Tim Dorr. Both of us are doing this in our spare time, and there's only so much we can do. If you're using Redux, and you feel there's deficiencies in the docs or how it's being used, don't just complain - _please_ offer some help so the community can benefit!
[0] https://github.com/markerikson/redux-starter-kit
[1] https://github.com/reactjs/react-redux/issues/890
[2] https://github.com/reactjs/react-redux/pull/919
[3] https://github.com/reactjs/react-redux/pull/898
I'm serious about the request for a docs PR. I'll agree that our docs are currently a bit weak on "real-world" app architecture instructions. If you feel there's specific advice that should be in there, _please_ file a PR! I'm already swamped with other things on my task list, and simply don't have time to add major new sections to the docs myself right now. I keep begging the community for help improving the docs so we can make things better for everyone, and I have a bunch of open issues tagged "docs" I've been trying to get help with, yet we get almost zero actual meaningful contributions.
I'm not sure how HOCs vs render props "leads people to make poor design decisions".
The Redux team's main focus in the near future is figuring out how to update React-Redux to better work with the upcoming async React rendering capabilities [1]. We've got a couple open PRs atm, one that's trying to fix the "strict mode" warnings [2], and one I did a few weeks ago that experiments with using the new context API for better compatibility [3]. The immediate goal is to keep the public API the same to provide basic compatibility with async React behavior, but longer-term, we may have to rethink the API to fully take advantage of what React can do. We aren't planning to add a render props API right now, but that could be on the table for a v6 API change in the future.
Again, right now there's two primary maintainers: myself, and Tim Dorr. Both of us are doing this in our spare time, and there's only so much we can do. If you're using Redux, and you feel there's deficiencies in the docs or how it's being used, don't just complain - _please_ offer some help so the community can benefit!
[0] https://github.com/markerikson/redux-starter-kit
[1] https://github.com/reactjs/react-redux/issues/890
[2] https://github.com/reactjs/react-redux/pull/919
[3] https://github.com/reactjs/react-redux/pull/898
> I'm not sure how HOCs vs render props "leads people to make poor design decisions".
This surprises me.
A render prop doesn't force any particular component interface. You just get a function and do whatever you want with the arguments (including just passing them along as props to another component, if you want).
HOCs force all the stuff you want to pull out of state to be passed as props, even if those props are not the ideal interface for the component you're wrapping, and they output a new component that you have to use instead of the original. Combined with derived state like reselect, this can lead to very weird component props that you'd never even consider if you were just designing a dumb-component without consideration for Redux.
This surprises me.
A render prop doesn't force any particular component interface. You just get a function and do whatever you want with the arguments (including just passing them along as props to another component, if you want).
HOCs force all the stuff you want to pull out of state to be passed as props, even if those props are not the ideal interface for the component you're wrapping, and they output a new component that you have to use instead of the original. Combined with derived state like reselect, this can lead to very weird component props that you'd never even consider if you were just designing a dumb-component without consideration for Redux.
Honestly, I've never used render props yet myself, for a variety of reasons, so I just don't have the experience to understand your concerns there.
As I said: if you have specific concerns that you think can be resolved by changes in the docs or the Redux/React-Redux libraries, please file an issue so we can discuss them in more detail.
As I said: if you have specific concerns that you think can be resolved by changes in the docs or the Redux/React-Redux libraries, please file an issue so we can discuss them in more detail.
The real irony of redux is that most of the project specific customization has to do with dealing with the boilerplate
I am new to React and Redux so I might not have a well informed opinion. Also, I see the value of Redux and I use it in my projects.
But it's awkward setting up a global event handler with switch statements. And it seems like adding new functionality should require one step instead of three (updating a reducer file, updating an action file, and updating mapStateToProps).
It's like Redux operates on a different paradigm than Javascript and React. I do not think I'm knowledgeable enough to suggest any solutions.
But it's awkward setting up a global event handler with switch statements. And it seems like adding new functionality should require one step instead of three (updating a reducer file, updating an action file, and updating mapStateToProps).
It's like Redux operates on a different paradigm than Javascript and React. I do not think I'm knowledgeable enough to suggest any solutions.
You might want to read Dan Abramov's post "You Might Not Need Redux" [0] and my own post "The Tao of Redux, Part 1 - Implementation and Intent" [1] to better understand the tradeoffs involved.
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
I've been using redux-zero on my latest projects with reasonable success. It does away with the distinction between actions and reducers, so you're basically just calling functions that update the app state.
This eliminates almost all boilerplate-ish code compared to redux, but it comes with its own caveats. I think it's a solid choice for small to medium size applications.
https://github.com/concretesolutions/redux-zero
This eliminates almost all boilerplate-ish code compared to redux, but it comes with its own caveats. I think it's a solid choice for small to medium size applications.
https://github.com/concretesolutions/redux-zero
I created my own library after finding redux boilerplate heavy.
I haven't publicized it yet, but you can see it here - https://github.com/gunn/pure-store
It supports full typescript typing, and uses Immer to allow very direct store updates with immutability.
It supports full typescript typing, and uses Immer to allow very direct store updates with immutability.
Wow that look amazing, how can I subscribe react to the store? Will each component need something like mobx observer?
I find conceptually Redux is straightforward enough, just really wordy. I think perhaps if I got to choose again I might consider Mobx. I still use it for my react stuff but most new stuff I'm using Vue.
Mobx and Redux have slightly different use cases, IMO. I prefer Redux for larger projects and Mobx for smaller ones, though I've only used Redux in production so far.
Mobx. I went from redux fanboy to using mobx exclusively.
I'm somewhat regretting not moving over to Vuejs from React when I had a better time opportunity. And I actually like JSX.
The best if you learn and practice the following four libraries and frameworks: React, Ember.js, Angular, Vue. You will see different concepts and you gonna be a real professional frontend dev. For example, you can create a simple interface or widget with React, but if you have to develop a complex big web application, Ember or Angular is a better choice. Most of these frameworks have great support, community and matured. Learning Ember is so easy as React: http://yoember.com
That's why I am going to wait till next year to start learning JQuery. Should be stable and mature by then.
Too late, http://youmightnotneedjquery.com/
The left column of that site only confirms (for me) how much friendlier Jquery is and that I don't want to give it up.
The site only goes to IE10 though.
The first three examples, which are probably the worst, improve greatly in more modern browsers that include the fetch() API.
In my view even the jQuery examples look a lot better if you can write ES6.
The first three examples, which are probably the worst, improve greatly in more modern browsers that include the fetch() API.
In my view even the jQuery examples look a lot better if you can write ES6.
The first example is not really apples to apples as it doesn't even have error handling which makes the native function look longer. Probably because getJson doesnt support errors by default and you have to use promises http://api.jquery.com/jquery.getjson/
I ran into this issue of jquery silently failing a while ago and will always remember that pain point
I ran into this issue of jquery silently failing a while ago and will always remember that pain point
I don't think I've ever used getJSON(), only ever the longer form ajax(), and never had issues with error handling, well at least since jquery 1.9 when deferred promises came good. Using .then() to chain events together is very smooth, what I always wanted. I'm lightweight with JS mostly though!
The first time I saw that site, I assumed it was a joke. Seems more to me like it's trying to tell people how nice jQuery is. Who would look at that and walk away with the opinion that jQuery is unnecessary?
jQuery is still great for web applications.
The site suggests you try not to make it a dependency if you're writing a JavaScript library. I also suggest vanilla JavaScript for simple pages that need just a smattering of interactivity.
The site suggests you try not to make it a dependency if you're writing a JavaScript library. I also suggest vanilla JavaScript for simple pages that need just a smattering of interactivity.
I think it is unopinionated. I like it very much because it teaches how to do things in plain javascript.
The idea is that if you're building your own Javascript library, you can avoid the huge dependency of jQuery.
If you're developing a user-facing app, then yeah, jQuery is still pretty darn helpful.
If you're developing a user-facing app, then yeah, jQuery is still pretty darn helpful.
Maybe the next step is a utility that "recompiles" or "statically links" jQuery JS into plain JS?
Probably next big thing will be straight web components or UI libraries like react or angular converting to web components. So everything should be nicely interoperable in the future, it'd just be a matter of how your modeling your data.
Web components are a regression, though. There's nothing in the slightest that would make interop possible. They just wrap a shadow root, and within you are greeted with a naked dom again, which calls for a framework to drive it.
Imagine for every 10 components you pull you'd load 10 separate frameworks - unless they all come from the same source. These "components" wouldn't be able to know one another or work together at all. The only thing web components are good for are encapsulated styles, but that hasn't been a problem for many years now.
Since they've come up with the idea the web has moved on. React has progressed to such an extent that javascript has effectively left the browser, drives full-native applications, renders on the server, makes interop possible that no piece of technology has been able to pull off before, where you can share code and semantics on pretty much every platform while being able to re-use eco system components: https://news.ycombinator.com/item?id=16198843 and https://github.com/gaearon/react-blessed-hot-motion
Throwing all this away, we'd be back in a browser-tied web driven by dumb-components, and for no reason at all.
Imagine for every 10 components you pull you'd load 10 separate frameworks - unless they all come from the same source. These "components" wouldn't be able to know one another or work together at all. The only thing web components are good for are encapsulated styles, but that hasn't been a problem for many years now.
Since they've come up with the idea the web has moved on. React has progressed to such an extent that javascript has effectively left the browser, drives full-native applications, renders on the server, makes interop possible that no piece of technology has been able to pull off before, where you can share code and semantics on pretty much every platform while being able to re-use eco system components: https://news.ycombinator.com/item?id=16198843 and https://github.com/gaearon/react-blessed-hot-motion
Throwing all this away, we'd be back in a browser-tied web driven by dumb-components, and for no reason at all.
I agree, the libraries will get lighter, just like jQuery has been doing for some time. I tried Vue again recently, and it was a 30 second copy/paste and it just worked instantly. 2 minutes later I had an example working inline with a project I am working on. (how long does it take to build your first React app?)
Web components are the dream of sharing code widely across many different systems, just like HTML, CSS and JS do. This is why it will beat React in the long term, wrapped in a lighter weight set of frameworks.
Just the other day there was an article discussing how the virtual dom could be improved with a static dom, and then only partially updated at the edges, something React isn't even designed to do. (ie, it does a complete diff of the dom and manages the entire view, correct me if I am wrong here)
Finally, if performance is your game, browser optimized code, whether it's web assembly or simple improvements to components, it will always beat a virtualized layer on top of it. Again, React will lose on this point too.
The question is, how long will it take before there truly is something better widely available? Or is it here already and we can't see it's value yet?
Web components are the dream of sharing code widely across many different systems, just like HTML, CSS and JS do. This is why it will beat React in the long term, wrapped in a lighter weight set of frameworks.
Just the other day there was an article discussing how the virtual dom could be improved with a static dom, and then only partially updated at the edges, something React isn't even designed to do. (ie, it does a complete diff of the dom and manages the entire view, correct me if I am wrong here)
Finally, if performance is your game, browser optimized code, whether it's web assembly or simple improvements to components, it will always beat a virtualized layer on top of it. Again, React will lose on this point too.
The question is, how long will it take before there truly is something better widely available? Or is it here already and we can't see it's value yet?
I recently found https://svelte.technology and looking forward to trying it out. It has no run-time like React or any other virtual DOM engine, but instead does compile-time static analysis.
It is a Rich Harris project (authored Rollup, Ractive, Bublé) so might be worth paying attention to.
It is a Rich Harris project (authored Rollup, Ractive, Bublé) so might be worth paying attention to.
Ractive was a neat little library which was under appreciated. React took over the world with all the immutable - one way binding and virtual Dom thing.. otherwise ractive was far lighter and better than Angular
I still use Ractive in some of my side projects. The API is simply brilliant.
I personally think that it will be React(-like), but in Rust, using Wasm.
Have you seen https://github.com/DenisKolodin/yew?
It seems that way, but the fundamentals are simple: functional/declarative programming using self-contained components, just like using regular HTML tags where you pass in all the attributes in the tag to customize it, but now with javascript for much more flexibility in what you can pass in via those attributes.
Those fundamentals are useful everywhere, like backend event-sourcing, CQRS, message-driven actor systems, and even all of the other libraries like Vue, Angular, etc. Learning any of these is like learning 80% of the rest.
Also React has some of the best release and upgrade notes along with tooling so that you can take an app through versions very easily.
Those fundamentals are useful everywhere, like backend event-sourcing, CQRS, message-driven actor systems, and even all of the other libraries like Vue, Angular, etc. Learning any of these is like learning 80% of the rest.
Also React has some of the best release and upgrade notes along with tooling so that you can take an app through versions very easily.
React will be around a while due to the ecosystem and the fact massive companies are using it. Big companies aren't going to rewrite their entire front-end for the next flavor of the month framework. React-native gives it staying power as well.
You could start with mithril.js, it's a react-like vdom library with a minimal set of api, and vanilla JS for everything else.
I've been using it the past 6 weeks and super happy with it. I'm sticking with the hyperscript form of it, but you can use JSX if you want.
I've been using it the past 6 weeks and super happy with it. I'm sticking with the hyperscript form of it, but you can use JSX if you want.
[deleted]
90% of what you learn will be high-level transferrable concepts, that you can already apply to Vue or Elm or whatever else.
i fear that eventually you'll be able to just design something in Sketch and press a button for the rest...
And then be asked a dozen questions how the layout should behave on small and wide screens, should the headline be ellipsized or word-wrapped? I don't see a general purpose solution for this kind of problem coming anytime soon.
Why not have defaults for that and let u choose it if needed?
...uhhh, Sketch has had artboards for ages
[deleted]
Not a single lesson titled: "How to write tests"
With snapshots, while not perfect, they do catch a lot and are easy to do (and more importantly, easy to update when things change). React components are relatively easy to further test with enzyme and jest.
Without a focus on instructing people how to do testing, people never bother.
With snapshots, while not perfect, they do catch a lot and are easy to do (and more importantly, easy to update when things change). React components are relatively easy to further test with enzyme and jest.
Without a focus on instructing people how to do testing, people never bother.
I’ve been through a few “intro to react” courses like this now, and I have not come across a single one that talks about testing at any length, which seems insane to me. When I was learning Rails many years ago, test-driven development was all the rage.
React, with it’s declarative approach, stateless components, immutable state, etc. seems purpose-built for testability. TDD with React should be ridiculously easy, but I wouldn’t know, because no one seems to want to talk about it.
React, with it’s declarative approach, stateless components, immutable state, etc. seems purpose-built for testability. TDD with React should be ridiculously easy, but I wouldn’t know, because no one seems to want to talk about it.
The culture doesn't exist in JavaScript land because historically it has been difficult to do. The tooling sucked. It is getting vastly better, but sadly, it will take effort to get back into the practice.
I hope that more people building the learning courses will focus on that. If I had time, I'd do one myself, as I now heavily test all my React stuff. I refuse to build another webapp without proper automated unit testing. It catches so much stuff.
I hope that more people building the learning courses will focus on that. If I had time, I'd do one myself, as I now heavily test all my React stuff. I refuse to build another webapp without proper automated unit testing. It catches so much stuff.
No offense, but I feel like this is not a good example to follow.
The first examples are better off with just using snapshots. Even if the author is trying to explain the concepts, it is really poor to show bad examples that could be covered by a simpler solution. If I read that and didn't know about snapshots, I'd think to myself, "why am I testing strings?" and then skip testing entirely.
Mocking Axios also seems like the wrong way to approach things. I'd extract the networking code from the presentation code. Possibly by using mobx-state-tree (which is an epic solution to a hard problem). This way, I wouldn't even need to mock Axios at all and I could then just take advantage of snapshots again by providing actual mock data to my components directly.
The first examples are better off with just using snapshots. Even if the author is trying to explain the concepts, it is really poor to show bad examples that could be covered by a simpler solution. If I read that and didn't know about snapshots, I'd think to myself, "why am I testing strings?" and then skip testing entirely.
Mocking Axios also seems like the wrong way to approach things. I'd extract the networking code from the presentation code. Possibly by using mobx-state-tree (which is an epic solution to a hard problem). This way, I wouldn't even need to mock Axios at all and I could then just take advantage of snapshots again by providing actual mock data to my components directly.
Fantastic tutorial. Easily-understood bite-sized chunks instead of tedious, hour-long lessons. Got me through React after several failed attempts. Well done Dimi.
Thanks!
Hey this is awesome. I had no idea what React is. And i was overwhelmed with the volume i had to learn for these many years, for which i delayed. When I saw this tutorial is around 2 hours, I decided to give a try. I am around part-8. I am very much impressed the way it is structured and presented.
1. I would like to know, if there are any such "free" tutorials related to web development, which are short and in-depth, and covers a breadth and depth of knowledge.
2. Are there any live coding walk-through tutorials of real world projects/examples, that helps you get complete understanding of development process?
By watching professionals in action, we can learn a lot from them, such as best practices, thought process, handling issues and problems and much more.
2. Are there any live coding walk-through tutorials of real world projects/examples, that helps you get complete understanding of development process?
By watching professionals in action, we can learn a lot from them, such as best practices, thought process, handling issues and problems and much more.
Hey this is awesome. I had no idea what React is. And i was overwhelmed with the volume i had to learn for these many years, for which i delayed.
When I saw this tutorial is around 2 hours, I decided to give a try. I am around part-8. I am very much impressed the way it is structured and presented.
1. I would like to know, if there are any such "free" tutorials related to web development, which are short and in-depth, and covers a breadth and depth of knowledge.
2. Are there any live coding walk-through tutorials of real world projects/examples, that helps you get complete understanding of development process?
By watching professionals in action, we can learn a lot from them, such as best practices, thought process, handling issues and problems and much more.
1. I would like to know, if there are any such "free" tutorials related to web development, which are short and in-depth, and covers a breadth and depth of knowledge.
2. Are there any live coding walk-through tutorials of real world projects/examples, that helps you get complete understanding of development process?
By watching professionals in action, we can learn a lot from them, such as best practices, thought process, handling issues and problems and much more.
[deleted]
This is awesome course. I'm watching the videos and coding last 2 hours. Very happy with what I was able to do in such a short period.
Thanks!
Nice tutorial! Nice site too, would love to see more tutorials for Angular, Vue and more.
Thanks!
Does anyone have an opinion on how this compares to React for Beginners (https://reactforbeginners.com/)? Besides the price tag, of course.
This looks neat, thanks for sharing!
What are the prerequisites for this tutorial?
Hi, i think before learning any Framework or library you should have good knowledge of language itself, in this case Javascript.
The number one thing I’d like to strengthen is the process of building a react component for publishing on NPM. It’s way different from building something with create-react-app. I need a solution that has zero config, has HMR, the latest JavaScript and automatic deployment for demos on github pages. I have so many components I could publish, but just can’t be bothered to figure this out.
Hey! I have edited create-react-app to build React libraries with it, it has exactly same features as CRA.
https://github.com/DimiMikadze/create-react-library
https://github.com/DimiMikadze/create-react-library
Looks good, though I would like a better support for github pages out of the box.
I've been using nwb for that
https://github.com/insin/nwb
Awesome, I might really enjoy this.
Extracted boilerplate from some of my libs:
https://github.com/alexkrolick/react-lib-quickstart
Want to port this to a CLI eventually, too
https://github.com/alexkrolick/react-lib-quickstart
Want to port this to a CLI eventually, too
You can build a complex application with zero configuration if you follow this tutorial: http://yoember.com
One thing completely missing from courses is how to handle animations.
Most React apps have no animations whatsoever (including mine, because I have no idea how to implement them), but they're important for usability IMHO.
Most React apps have no animations whatsoever (including mine, because I have no idea how to implement them), but they're important for usability IMHO.
Pose [0] was posted on HN a few days ago. I haven't tried it, but its API looks super clean. HN Discussion [1]
[0] https://popmotion.io/pose/
[1] https://news.ycombinator.com/item?id=16701756
[0] https://popmotion.io/pose/
[1] https://news.ycombinator.com/item?id=16701756
I got excited about Pose but when I tried it out I saw a lot of unexpected and undocumented behavior. Seems promising but docs needs more work and examples!
Creator here - have you got any specific examples of this behaviour? I’d be glad to hear of them
I was trying to create a slide down animation, but could not figure out if Pose is dependent on the height property or not. Some times transforms worked-ish and sometimes not.
Hmm probably because height and width are converted to transforms as FLIP animations. Maybe I’ll look into making that opt-in. Thanks dude.
Looks great!
http://airbnb.io/lottie/ the perfect solution (works for React and React Native too).
Wow, this looks amazing. Have you used it for web?
I was just reading a bit about animations in react, i honestly hadn't thought much about it before. It was because of an HN post about this library https://github.com/kutlugsahin/react-smooth-dnd. But just quickly looking back it seems they use CSS transitions for animations. That is an option, not sure how limiting it may or may not be.
Yes, it's the only way that it makes sense. It's not that limiting, you can probably use animate.css.
I absolutely have to look into this soon.
I absolutely have to look into this soon.
I'm literally working on a lib to solve this right now, specifically to be used with react-router. If you want I can contact you when finished and you can give it a whirl.
Implementation will look something like <TransitionGroupRoutes><CSSTransitionRoute path="..."/><CSSTransitionRoute path="..."/></TransitionGroupRoutes>
Implementation will look something like <TransitionGroupRoutes><CSSTransitionRoute path="..."/><CSSTransitionRoute path="..."/></TransitionGroupRoutes>
Transitions are fine, I'm more worried about how to give an indication that a panel has been open or similar.
I'll check it out, though! If you have a mailing list feel feel to add me: [email protected]
:-)
EDIT: I think your comment below is too deeply nested and it doesn't let me reply. However: I think a mailing list is useful even for personal project. In the event that the project gets traction, it would allow you/motivate you to keep working on it and improve it (I'm a professional side project creator).
As for nested animations, it might make sense to chain them..? Not sure.
I'll check it out, though! If you have a mailing list feel feel to add me: [email protected]
:-)
EDIT: I think your comment below is too deeply nested and it doesn't let me reply. However: I think a mailing list is useful even for personal project. In the event that the project gets traction, it would allow you/motivate you to keep working on it and improve it (I'm a professional side project creator).
As for nested animations, it might make sense to chain them..? Not sure.
Good advice, I'll set it up. The problem I ran into with react-router-redux was the requirement of using location to provide the value for a key on CSSTransition. I had to use this implementation to solve the problem of the missing exit animation. https://reacttraining.com/react-router/web/example/animated-...
This uncovered a new problem for nested animations. The high-level page transition animation occurs even when the url root does not change. So I need to be able to ignore animations on Route components located high in the VirtualDOM, and apply animations (sometimes different animations) on Route components located further down.
Maybe you already know of an elegant solution to solve this problem? If so let me know! In the meantime, I'll keep bang'n on this.
Edit:
Concerning giving an indication that a panel has been opened, I'd just use CSSTransition wrapped around whatever element that is going to be introduced to show that it has been opened. Then define your 'enter' animation in css.
If that seems like overkill, and you can't use did mount to determine if the animation should be applied, then I'd just add a css className to your element to introduce some animation defined in CSS.
Obviously, I may be misunderstanding your use cases here. The above are just knee-jerk thoughts on it.
This uncovered a new problem for nested animations. The high-level page transition animation occurs even when the url root does not change. So I need to be able to ignore animations on Route components located high in the VirtualDOM, and apply animations (sometimes different animations) on Route components located further down.
Maybe you already know of an elegant solution to solve this problem? If so let me know! In the meantime, I'll keep bang'n on this.
Edit:
Concerning giving an indication that a panel has been opened, I'd just use CSSTransition wrapped around whatever element that is going to be introduced to show that it has been opened. Then define your 'enter' animation in css.
If that seems like overkill, and you can't use did mount to determine if the animation should be applied, then I'd just add a css className to your element to introduce some animation defined in CSS.
Obviously, I may be misunderstanding your use cases here. The above are just knee-jerk thoughts on it.
Sure! Will do. Honestly, I was just building it for myself, so no mailing list. But I'd be excited to see how you like it.
The problem I'm aiming to solve is nested route animations, and allowing for different animations to be applied depending upon the previous route in history.
The problem I'm aiming to solve is nested route animations, and allowing for different animations to be applied depending upon the previous route in history.
I really like React Motion [0] because the API is really simple and the concepts are pretty easy to grasp. If you like the concept of Pose (springs), React Motion might be more predictable.
[0] https://github.com/chenglou/react-motion
[0] https://github.com/chenglou/react-motion
Hey, sorry to hear that, i thought it was more of a CSS topic then React's and because of that i have not recorded lesson regarding animations. I don't know if it help you, but in most cases i use CSS transitions with classname manipulations and lifecycle methods if needed.
Ah, no I'm just saying in general :-)
Class names and CSS transitions have worked just fine in my experience. That said, I'm much more in favor of external stylesheets than coupling styles with components themselves. It seems like the trend with React is to do the opposite.
Yes, it's the component's responsibility to animate a panel that is part of it, I would think.
Perhaps providing hooks to override the behavior, but even not.
Perhaps providing hooks to override the behavior, but even not.
Also, the Reactiflux chat channels on Discord [2] are a great place to get help and learn. We've always got a bunch of people hanging out happy to answer questions. Come on by and join us!
[0] http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...
[1] https://github.com/markerikson/react-redux-links
[2] https://reactiflux.com