From what I have been researching, ReactJS is the new craze in the world of front-end development. I can find few articles that are able to provide a bias free look on ReactJS. There is only praise for it, but should it be used everywhere? I know an html.erb file with javascript can accomplish what ReactJS can do. Everything has its place. Where does ReactJS and React Native fit in? Specifically when should they be used? I know JavaScript can handle a lot, but of those things it probably shouldn't handle, or there is a better solution.
I would greatly appreciate guidance on these questions.
React has many cool features and is one of the best libraries for using for building UI apps
it utilizes something called the virtual dom to enhance performance in applications
it has a really intuitive pattern with storing state in local components which can be passed down to children components as props.
it integrates well with state management frameworks like Redux (there is a helper package called react-redux which makes the integration seamless) but it also has it's own context API which can be used for wider ranging state
it recently introduced the concept of hooks. these replaced lifecycle methods which were popular in previous versions and are now a cool way to "hook" into components and utilise functionality whilst the component mounts and unmount
of course, like with everything, there are alternatives. you can just use plain old vanilla which has it's own benefits or you can choose a popular alternative such as Vue.js.
There is no hard and fast rule specifically when it should be used. the ball is in your court
Related
If I look at the polymer shop I am instantly sold on wanting to use this as a starter for my web shop. Not just because it's already a web shop (full pwa technology) but because it has excellent (offline) experience on browser/mobile, has proper documentation and is still maintained.
But then look at the polymer home page and see the project is based on an outdated polymer version and even the fact that it's using polymer in the first place is curious:
The Polymer library is in maintenance mode. For new development, we recommend Lit.
So my question is if lit will have the rich choice of web components that the shop seems to be depending on?
This may be a dumb question but I skipped polymer other than looking at some exciting news in google IO
The goal of Lit, and of Polymer before it, is to help build web components and applications using browser features as much as possible.
For instance jQuery wrapped all the different browser features in it's own syntax, to the point where developers were learning jQuery, rather than Javascript. jQuery components assume that you have jQuery and rely on those jQuery methods to function.
Both Lit and Polymer championed web components - this makes each component much more self-contained. Using a mix of jQuery and any of its competitors was really painful, but that isn't the case here.
All the components used to build that shop are stable and still on npm. You can use them if you want and I have live applications that still use them.
However, championing the latest browser features has its risks. Polymer relied heavily on HTML Imports (that only Chrome ever implemented and were ultimately dropped) and its own template library. It was ultimately ported to ES6 modules, but the core design is far less suited to it. Those components are pretty stable, but you don't really want to start anything new with it.
Lit is quite a lot less opinionated than Polymer, and much lower level. For instance Polymer supported two way binding with {{property}} syntax, but had to make assumptions (that often broke) about what you were doing to support it. Lit drops that for extremely stable property setters but if you want to users to write values you have to subscribe to events and roll that yourself (Lit does make events very easy to manage though).
So if you're going to build your own web components or application Lit is by far the better choice, and LitElement is lightweight and extremely compatible with everything else. You can use those Polymer shop components in Lit (I have) but for most of them there are newer alternatives, in particular MWC.
I've been searching for a while about React's hooks now, and one question became persistent in my head. Will hooks overthrown redux? This is a fairly old discussion so first a little bit of context :
State Management with React Hooks — No Redux or Context API
What do Hooks mean for popular APIs like Redux connect() and React Router?
redux-react-hook
A lot of people (React's team included) seens to think that redux and similars will just going to adapt to the new API, turning the HOC's approach obsolete, but my question is:
With custom hooks, use reducer, and a well thought logic why do I need Redux at all? I mean, isn't just more performatic to dispatch your actions to a single reducer? I've found a lot of material about it, but none of those seems to have a definitive answer (maybe because there aren't one?), so I would like to know what do you think about Redux's future?
It's really hard to say at this time. The redux team is actively updating the product to include some nice features. However, one of the creators of redux (https://github.com/acdlite) seems to be on a path to destroy his old applications in favour of new features in react.
That being said, Redux is a tested and known library that a lot of people are comfortable with. I do not believe it a bad idea to start a new project with redux Today, tomorrow, or in a year. Tech does not die overnight. if it serves a purpose it's going to live on.
However, I do think context and hooks are a great alternative to redux, but the community simply does not know how to use it yet.
Nope, definitely not.
I addressed this in my Reactathon 2019 talk on "The State of Redux".
Summarizing: hooks mostly offer ways to do the same kinds of things you could already do, like local component state and avoiding prop-drilling via context. If that's all you were using Redux for, then you probably didn't need Redux in the first place. But, hooks have their limitations, and there's lots of additional use cases for choosing Redux.
Also, note that we are currently working on designing a public useRedux()-type hooks API for React-Redux.
More than a year has passed since this question was posted.
I want to add that in my opinion Redux has lost some relevance...
2 players in my opinion have stolen a big share of Redux's position in the React market:
People have learned how to combine useReducer with useContext to
implement a much simpler solution and without third party
dependencies. With the advantage that the React team is behind it;
which means we will get constant improvements tightly integrated
with the React framework.
MobX has been growing it's user base. Mainly because it provides an observer pattern which requires much less boiler plate code than Redux. (This could be debated).
So even though Redux remains widely used for React projects I foresee this will be gradually reduced overtime... - no pun intended... well may be a little bit ;) -
Specially for green field development!
I am new in Angular2. Angular provides various options for managing the state of an application like ngrx/store, angular services etc. if we manage the state of the application using ngrx/store then we require an external library but in case of angular services do not require. What should be used for managing the state of an application? what are the pros and cons of each approach? Is there any recommendation that is provided by the angular community?
You do not need ngrx/store to implement a redux-store. You can implement one yourself. There are multiple tutorials online showing how to do it in a lightweight way. But ngrx/store is developed and supported by people from google and so it is a mature framework you can trust, which also provides some neat features, like effects for asynchronous events and immutability checks in development.
The main question is whether or not you should use the redux pattern/store in general. This highly depends on your application architecture. For smaller applications it could be too much work, especially if you don't have clear user stories and things might change quickly.But i f you have a big SPA, in general it is recommended to use a central data flow store, e.g. redux. It ensures the dataflow in your application is unidirectional and there are no circular dependencies at important parts of your application, causing weird bugs in the future as your application gets more complex.
Also even in a SPA you have things like UI-Libraries which do not belong in a store. A button prototype being enabled or disabled is something only its component should be aware of. But the same button in usage in the application module should represent a particular functionality being offered or not and that should be represented in redux.
I highly suggest you look at the ngrx-store example app and see the benefits and shortcomings yourself.
I have a performance issues with Angular (as many others). I wish to change only the view layer to either reactjs or Mithril. I found examples of React js (for example http://www.bimeanalytics.com/engineering-blog/you-put-your-react-into-my-angular/), but not of Mithril.
Can anyone advice to the pros and cons of using Mithril as an angular view vs Reactjs?
Thank you!
I don't think there's an objective answer here, and as a Mithril user I have my biases, but here is what I think.
In terms of philosophy, Mithril and React are quite similar: you write view functions that describe how your app should look at any given time. In terms of rendering performance, I don't think there's a clear winner. There are links / blog posts that say Mithril is faster than React, and vice versa.
So instead what I think you should focus on is:
1) Which API do you prefer? With React you should use JSX lest you have to reverse engineer their documentation. Mithril also just has one lifecycle hook (the view function), whereas React has several (such as shouldComponentUpdate) -- do you need all those hooks?
2) Community support -- React is the clear winner here, and the fact that there are existing examples of integration with Angular is a win.
3) Compatibility - DOM redrawing / diffing in React is done when data changes, just like Angular, but Mithril's redraw is centered around user interaction (such as clicks, route changes, ajax requests). You can manually redraw, but that's less desirable. I don't know how well Mithril will fit into an Angular setup.
Should you decide to use Mithril, I'd encourage you to use the Google group (https://groups.google.com/forum/#!forum/mithriljs) as a resource, or at least report back on your experience.
Mithril and React have many similarities. I've used both of them and here are some pros and cons.
Mithril
Pros: It's loading times are very fast. This is because it's templates are compiled first and then served to the browser. You can write Mithril views in JavaScript. Small size, good documentation and doesn't force you into a predefined structure.
Cons: Small API can make it unsuitable for larger more complex projects.
ReactJS
Pros: React's one-way data binding means that it's easy to see where and how your UI is updated and where you need to make changes. It also provides server-side rendering, virtual dom support, good debugging tools, easy to write tests, easy to reuse components, flux architecture patterns, and extensive SVG supports etc.
Cons: Heavy on memory compared to Mithril, not a complete solution as it mainly focuses on the view, and need to learn a new syntax etc.
In my view, React is overall preferable. But, if your application doesn't need all these extra stuff that React provides, you should go with Mithril.
I'm learning React but I'm still unsure on how to grow it up into a full-fledged app.
For the M and the C, what frameworks are cool to use with it? What if I want to go functional? Should I just use jQuery?
What about Routes, Ajax and the other things that many frameworks offers us?
You can actually go simply for Flux and react-router
Flux is based on the usage of Stores, Actions, and Dispatcher (depending on the implementation of Flux you use).
The Stores will play the role of the Models in an MVC framework.
The Controller (C) part is trickier to explain in the context of Flux, but it would be probably some of your React components that could be considered controller, combined with the Stores.
React-router makes it easy to manage routing in your React apps.
My more general advice would be to not look for "cool" frameworks to make your apps, but ask yourself what is going to be the fastest to implement with, the easiest to maintain and test, and what stack is going to be the simplest to do the job. Sometimes, simpler is much better.
For the M part I think Play Framework has a very simple way to create models. Your controller implementation depends on how you want to do it but it would definitely be a mix of both front end javascript to transfer data from the view (if you plan on using ajax) and a back end component. Play would help you out with the backend part of the controller.