when application gets some stimuli from outside (user typed some text in input field, or result of HTTP request has arrived), it emits write event - or, in Redux/Flux slang, dispatches an action.app view uses ( reads, not writes) app state to render.One-way flow is basically the giant cycle: These events are flowing between views and controllers (and services, such as HTTP backends) So your impression that that they're conceptually not too far from each other is not too divorced from their practical uses.ĭata flow here is a flow of write events - i.e.
BACKBONE JS VS REACT UPDATE
What separates one-way flow from two-way binding is a variable update on change. Implementations asideįrom a platform independent point of view, they're not so different. If your app depends on the state, you look at it before and after the action that triggered the change, and you make sure variables have the value they're supposed to. This makes problem solving quite straight forward. Point is, you always know when the stuff changes, and what caused the change. In React/Redux you dispatch actions which update the store (single source of truth) and then the rest. In React, you set the state's new value, which then causes a ReactDOM.render, which causes the DOM comparing/updating process.
But how does change detection work in this dynamic? Well, you trigger it manually. React makes the view redrawing process extremely efficient because it compares not the actual DOM but a virtual DOM it keeps on memory. To update the view, you need to update the model first, and then redraw the view. It means that the view always gets its state from the model. Needless to say, it can sometimesīe a pain to find where and when a problem occured. To not dive too deep into change detection in Angular, you trust it will update what you need when you change a variable, or when it gets changed after an observable resolves, but you'll find you have no idea how and when it runs, and sometimes it will not update your view after a variable changes. I found myself having to resort to tectChanges or n to force the view to update. What's the problem? You don't control the change detection mechanism. In Angular, you update a variable and its change detection mechanism will take care of updating the view, and viceversa.
As a rule of thumb you should keep in mind that developing NEW components in another language / scripting style is way smarter that re-developing the entire app (which would, as a matter of fact, break a lot of your given business logic and lead to endless nights of doing the same thing over and over).It's made possible by a mechanism that synchronizes the view and the model whenever either change.
BACKBONE JS VS REACT HOW TO
Or are parts of your code simply too verbose, un-testable or buggy? Then you should assume refactoring your code as much as possible instead of re-inventing the wheel.Ī last word: There have been several discussions in the Backbone.js/Marionette.js community about how to migrate an app to framework xy. Do you need two-way data-binding in forms? Well, that one goes to Angular. Do you have to deal with heavy data? Then keep on using Backbone.js. That is why you will first have to assess for yourself what your hybrid-app project really needs. However, if I would have to do the same job with more complex views, view-transitions, routes and all that mobile-related stuff, I'd probably choose a toolkit that can handle these scenarios much better and with less amount of code - such as Flutter, React native or even native programming. I did a hybrid-app project several years ago only using Backbone.js - and had no problems so far. No framework or toolkit is perfect, neither are Backbone.js or Angular (or PhoneGap / Ionic / React (native) / you call it)! If you want to migrate your app to another language, ask yourself for which reasons you would do so: Do you simply want to learn another language? Or has Backbone.js proven to fail in certain situations/scenarios? IMHO As a JS-developer you should be able to answer most of this question by yourself.
0 kommentar(er)
