Angular and Flux can they work together? - javascript

Flux is a unidirectional data flow originated in the React team, it hold many benefits (Undo/Redo, Easy to test, one State to the app, and more) and it would be nice to combine it with AngularJs.
Victor Savkin wrote a blog post on how to implement it using AngularJs, but he broke a basic concept of Flux by changing the store instead of re-creating a new instance of it. Another thing that bothers me is that Angular is using ng-model and data binding, using Flux means that we should not use these anymore...
Thinking about all these issues, sounds like Angular and Flux paradigmas are colliding.
Anyone ever really creating a working Angular in Flux that works (As expected)?

With the Flux folk recommending Redux instead, whether the latter and Angular can work together is perhaps a better question. On that, they certainly can be and I recently wrote a blog post http://simonh1000.github.io/2015/10/angular2-one-way-data-binding/. I'm not sure how efficient it is as Redux complement React whereas it substitutes for some of Angular's model handling.

Related

Multiple todo lists in a React Application (parent -> child relationships)

I have found a serious flaw I think in ReactJS. Although I admit this flaw perhaps might be a flaw in my understanding :) I am trying to build a simple Todo application (using TodoMVC), and when you try to use something like Redux for state managment, you run into very, very hairy issues when trying to process nested JSON, i.e. a database response that typically would include a parent node ("projects"> and then child nodes "todos") related to the parent.
Redux seems to want you to "normalize" the data from the response so it's immuatable. Not to upset anyone, but this seems like the most ridiculous thing in the universe. So, we build a SPA app to process json responses from our data....and then...oh wait, we have to build an ORM on the client to munge all that data into a different format to process it.
If this is the state (sorry no pun intended), of React, Redux and the like, Javascript frameworks should be abandoned. I built something in Rails in like 20 minutes. Of course it's not a SPA, but it was simple to create this MVC structure... not only does it seem extremely difficult, hairy and overly complicated in React, when Redux is added, it gets into the area of absurdity. Perhaps that is why we only see very very simple tutorials with all these tools.... building huge apps with them isn't possible.
So basically, in just trying to code a simple few lines of this example above with react and redux, I was lead to this:
https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape
Can someone prove me wrong? PLEASE. Just a simple codepen showing me you can have a parent "project" component, which you can add "todos" to as children and the ability to make MULTIPLE parent components, with MULTIPLE children without going down the rabbit hole above.
This is a serious flaw in my opinion if this is true. A showstopper.
Your question and understanding are wrong in a few ways.
For context, I'm a Redux maintainer, and I wrote the Redux "Normalizing State Shape" docs page you linked to.
First, you don't need to use Redux if you're using React. In fact, we recommend that most beginners should focus on learning React first, and only try learning Redux once they're comfortable with React.
Second, Redux is independent of React, although they're commonly used together. You can use Redux by itself, or with any UI framework (React, Angular, Vue, Ember, jQuery, vanilla JS, etc).
Third, normalizing is a recommended pattern, but it's not required. Per the docs page you linked, normalizing data has several benefits, but it's fine to keep your data nested if that works better for your application.
Fourth, there's many large complex apps that are written with React and Redux, not just todo examples. See the Apps and Examples list in my Redux addons catalog.
Both the React docs and Redux docs have links to many CodePen / CodeSandbox examples that demonstrate how to use them - see the Main Concepts and Tutorial pages in the React docs, and the Examples page in the Redux docs.
Also, the TodoMVC.com site has several React todo list examples you can look at.
I'd suggest that you take the time to go through the tutorials in the React docs. You may be interested in my suggested resources for learning React and learning Redux, as well as the articles and resources listed in my React/Redux links list.

Javascript object instead of Redux?

I'm currently build my first real app in React and decided to use Redux along the way.
After implementing Redux, it seems like a difficult way to just set a component state to a plain application global javascript object? I've read that Redux does some performance stuff, but if we were to use a plain javascript object and enforcing immutable state change together with forceUpdate() whats the point of Redux? Besides cool timeline dev stuff? What am I missing? :)
Thanks in advance :)
If you truly understood Redux, then I think that’s mission accomplished.
Redux simply adds a simple flow to managing a global JS object - global state. You can surely do it without Redux. After all it’s very small library.
So you’re not missing anything, I don’t think. Redux is just a really useful workflow that you can implement on your own. But given it’s simplicity and excellent architecture, it may be worth going with a proven solution.

React and Redux differences in code that should be used and not used (conceptual)

I'm working with React-Redux and just wanted a bit of clarification as it is a mental blocker for me.
Using the Redux libraries allows us to have a different architecture to manage state - ok.
But using this comes with a variety of helper functions and in the process of looking at online material I have found there are a number of ways of writing your code.
In terms of state management, Facebook's react docs includes stuff like componentWillMount, componentDidMount, getState, etc. Then there's connect(), Redux thunks, etc.
Is it correct that these should still be used when writing Redux-React? Does it defeat the point in Redux? I'm a little confused at where the line is drawn between the two in terms of how to actually write code?
As always, thank you for the advice
Check this official Redux tutorial section: http://redux.js.org/docs/basics/UsageWithReact.html
That will help you to understand how to use them in pair. Even better, check whole tutorial.

use react with angular

I started learning React and It's really amazing, I enjoy coding with React.
In official doc said that React can be used for UI only.
React is a JavaScript library for creating user interfaces by Facebook
and Instagram. Many people choose to think of React as the V in MVC.
So, Can I use React with Angular.js for UI? Is that a good idea or bad? (why?)
Googling, I found lib called ngReact. It allows use React Components in Angular.
What you think about this? Give me an idea.
Thanks in advance.
I have been using ngReact for an application which is written on angular.
We had to switch the view for some parts of the applications to react because of the constant data changes and is expensive for digest cycles.
angularjs is good to handle the ui for most applications unless you are looking at rendering a lot of data. Even in that case if the data is not changing you can use single binding of angular. If you have data that is constantly changing your view might get slow in angular that is the only downside with existing angular versions.
That being said using ngReact can become tricky at times. Mainly communicating with angular services, basic directives like ui-sref and react nested components.
Be sure of the reason for using ngReact.
using react, angular and even a combination should be more than a personal preference.
Ive recently my self started to learn React. And you are completly right React is just for UI and dosent support any Model / Controlers.
But mixing React & Angular for me seems a bit odd? Angular got its own template engine with their directvies (Angular 1.xx). So it would be a bit akward to match these too frame works.
If i was you i would look into this thing called Redux, witch is another way of doing flux architecture. This is also the architecture that React is initially thought upon. And its really powerful.
Here is a couple of nice to have to get into:
https://egghead.io/series/getting-started-with-redux - This is a free course on Redux (witch you want to use with storing data for you react views)
You can actually interoperate Angular and React really nicely with https://github.com/bcherny/ngimport. My team and I have used it successfully on our 10k file hybrid Angular+React project - let me know if I can answer any questions!

Are all Flux for Angular Libraries Experimental?

Facebook React can use a unidirectional data flow pattern called Flux to give structure to applications by using Views, Actions, Stores and a Dispatcher.
I have found the following Flux libraries for Angular:
ng-flux: https://github.com/JustinWinthers/ng-flux
angular-flux: https://github.com/brentvatne/angular-flux
song-flux: https://github.com/gah-boh/song-flux
And this sample: http://victorsavkin.com/post/99998937651/building-angular-apps-using-flux-architecture
Are any of these production ready?
Which ones have plans to migrate to Angular2 and integrate with the Component Router?
I can't seem to find any large application samples using any of these libraries. Additional links would be useful.
I authored ng-flux and I wouldn't say it's production ready since I haven't had the time to test it in a variety of projects. However I am using it in a fairly large enterprise class application currently. I agree that flux-angular has a good team around it and I'd recommend their library. Regardless, flux is simply a pattern that you can incorporate on your own. The issue with any Angular 1.x based approach is always the way Angular manages digest cycles and you have to sometimes jump through hoops for views to update in the background if you process data outside of the Angular namespace. In ng-flux I force a digest cycle if one hasn't occurred.
Flux as a pattern works well to me because it makes debugging and code separation much easier on larger projects, so my goal was to use this pattern on a project that already had substantial legacy Angular code and decrease the time it was taking to triage errors. It's an actuarial application with lots of calculations, so finding small data discrepancies fast was necessary. Writing ng-flux achieved this for me.
Regarding Angular 2, I think it will be easy enough to incorporate Facebook's dispatcher in your project and allow it to manage data flow. I think once Angular 2 is ready, based on what I've read so far it should be easier to use third party JS libraries - especially since Angular 2 will follow more of a web component based architecture somewhat similar to React. I've even seen promises that it will be easier (or more organic) to use third party routers, etc.... If this holds true, I doubt you'll actually need a library to manage a flux based data architecture in your Angular 2 apps. It should be fairly seamless to simply use something like the Facebook Dispatcher as a singleton (properly namespaced) object in your app that you can reference in your Angular components. I think most of the library authors out there realize this - it's more a problem for Angular 1.x apps to use this pattern than it will/should be for Angular 2 apps.
https://github.com/facebook/flux/blob/master/src/Dispatcher.js
I am not a pro in ReactJS, however I am not sure that integrating Flux with AngularJS is really a focal point for many Angular developers. With the release of 2.0, the Angular teams is continuing to make the framework more and more self-sufficient so people do not have to jumble together different libraries, but instead can just rely Angular to accomplish the task at hand.
That said, it seems like this flux-angular libary is stable with versions' 1.x, and it seems like it has pretty good support. I know it does not help your case when dealing with 2.0, however, it does seem like a solid enough API; but, then again, maybe I am just biased because of the functionality I have been able to replicate using Angular 1.2 & 1.3 :)

Categories

Resources