Most of the legit tutorial/demo out there are all talking about using Flux as a framework for the whole app. I am wondering if anyone has experience of building an app with multiple mini-flux-components. Because I am thinking in this way it might be easier to extract the mini-system out and then apply to other projects.
What do you guys think??
Nothing stopping you from instantiating multiple dispatchers, essentially creating multiple "instances" of Flux. The Dispatcher doesn't use any globals, so each instance is completely independent of the others.
I would avoid registering a Store with more than dispatcher, for the sake of keeping things simple and maintainable. To this end, a dispatcher should only span a fully modular domain of the application where the Stores under it's purview don't need to communicate with stores wired to different dispatchers.
Related
I am new to React js and I have been trying to understand what real problem does js frameworks like React,Angular solve and why one need to learn them.
Of Course when i see advantages of framework everybody talk about "Shadow/Virtual DOM, Router, Reusable Components etc" , but then I stumbled upon below links which talk something different
https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445
https://www.codementor.io/binarymuse/react-components-from-a-jquery-programmer-background-du107k2lz
but they were not clear to me
So i am meaning to understand how difficult it was to maintain js/jquery code before these framework came by.
Everybody is just asking to learn these frameworks because they are popular but none of them clearly explains why they are popular and what problem they solve and how they make our life easier when it comes to creating web-app from scratch.
Others have already mentioned the advantages and what these frameworks resolve.
I wanted to add what problems they can create:
I have seen many people that use a framework see it as a hammer and every website as a nail. In other words they either don't or can't figure out that in many cases a framework is not needed. I have seen web pages that are nearly 90% static data still download an entire framework just to provide drop menus or something else trivial.
Frameworks force you into a lifecycle and development style that, in some ways, make some things easier and other things much, much more complicated. AngularJS had a nasty digest cycle that often led to complications. Redux forces you to write much more code than needed just to handle state that on many pages is not needed. Vue, React, Angular all force you to either use their data creation functions, their way of rendering or their way of handling inter element communication. And none of these are faster than vanillaJS. Even virtual DOM has its issues.
The size of a framework is often much more than needed. I have several small libraries that do the majority of the work that a framework does but my code is in the sub 5K range if I load it all.
Some people that learn a framework first can not figure out how to write in raw JavaScript. They also tend to learn sloppy ways to write code. No, not everyone, but a large number people that did not start with vanilla JS write code that tends to be much larger and sloppier than needed.
It is best to avoid JavaScript except where really needed. Often I can use raw HTML and CSS to do everything I need to do. I find that it is rare that I need to use much JavaScript even in projects that exceed several thousand files. It is faster to allow the browser to process HTML and CSS, which all processes at compiled speeds and only use JavaScript for things you can not do in HTML and CSS.
You don't "need" to learn them, but many people and companies use them. The main advantage is being able to have your entire site on a single webpage, where you just modify the data and it handles changing the elements on the page for you. For instance, you can just think about "put the user's name here, and when they click the button, add another list field there", but you no longer have to think about "get this DOM element, set its innerHTML to the user's name, and when they click the button, create a new DOM element for input, another one for the label, get the container element, append the new children". It also allows you to more easily bind data to DOM elements, so you can just say "this field is for the variable 'numberOfItems'" instead of worrying about grabbing the DOM element and its value and storing it into numberOfItems when you need it; with React/Angular/etc. that variable will always be up to date with the user's input without you needing to update it.
TL;DR: The frameworks are not necessary, but they help automatically handle a lot of common, tedious DOM manipulation for you in a way more optimized than you'd likely end up implementing yourself, with less code for you, and all on a single page instead of having to reload the page every time you want to display new data or a new layout.
What is React JS?
ReactJS is an open-source JavaScript library that is used for building user interfaces specifically for single-page applications. It’s used for handling the view layer for web and mobile apps. React also allows us to create reusable UI components.
React allows developers to create large web applications that can change data, without reloading the page. The main purpose of React is to be fast, scalable, and simple. It works only on user interfaces in the application. This corresponds to view in the MVC template. It can be used with a combination of other JavaScript libraries or frameworks, such as Angular JS in MVC.
https://www.c-sharpcorner.com/article/what-and-why-reactjs/
This is a wide discussion about frameworks in general. Is easy to say React, Angular and so on makes easier to manipulate DOM elements and reuse components, but to apply frameworks usually are about if solve your problem.
in javascript we have load the webpage by using location.href but by using angular/react we the page updates automatically.
I have developed some SAPUI5 mobile apps and I'd like to merge them into a portal (with tiles) so I can switch between them as a "reputation".
Now I would like to know, what would be the "best" way to implement this case?
At the moment the apps have got a controller and views. My first idea was to build a "portal-app" which includes all the views of the other apps with an own controller but then I noticed that the performance has decreased (because all resources (OData-models etc.) load when starting the portal-app).
I also tried to link them (all with their own index.html) but this case seems not to be the right one.
So is there a way to load the views dynamicly or a whole app and how can I do that?
First of all, SAP's official solution for this problem is called SAP Fiori Launchpad. However, it's much more complex to set up (you need an underlying application server which holds SAP Fiori. You need to handle user roles and assign applications to roles). However, it's great for inspiration. (Here you can check it)
You can create a separate component which holds the references to other applications. Your applications can be referenced from Tiles.
I don't know the current implementation of your applications, but it's recommended to implement them as components (UI components if they have visual representation).
With components, you will be able to use Routing (navigating between views, or even components using hashes (urls)), which helps you to manage resources and services properly. With this you can prevent unwanted odata requests as well.
It can be a big step forward from a simple application architecture, but it's worth it.
Of course, you can implement one simple application without components. In this case you can experience the mentioned performance issues. Consider to move data intensive operations into event handlers and perform these tasks asynchronously.
I am creating an ExtJS 4 single-page web application, and coming across some issues deciding on the MVC-favoured way of defining and maintaining my application state. I am aware of the global nature of ExtJS 4's stores, and I like the idea of them, but the practicalities of them are called into question on a couple of points.
For example, I have models that could possibly need to scale into the thousands at some point, and the idea of loading all of these into the memory of the client's browser does not strike me as the best of ideas. I would have great performance concerns with trying to do this.
Additionally, my application will have windows, multiples of which that may be viewed at the same time, in addition to multiple grids on the same tab in a tab panel. These views are supposed to show a subset of the models based on their properties. If these views are tied to the same global store and its models, they will be affected by operations such as filter and will effectively be restricted to showing the same set of models, which is not what I am trying to achieve.
So my actual question is how do I go about handling this situation? I have read a similar concern on StackOverflow that called for the views to hold their own instance of the store rather than using the global instance, but I am not sure this fits the MVC pattern correctly. My current thinking is along the lines of having a controller that manages the state and holds the various instances of the stores so they are not directly tied to the views and yet they can still be accessed on event calls and by other controllers. Is this a good solution or am I missing something?
Well, there's a lot going on in your question. First of all, I think you are over-thinking stores a bit. Ultimately, a store is just a cache of model instances. So you can create as many instances of them that you want, depending on the requirements of your application. If you want to try to use a single store to manage the entire data set, you can certainly do that, but you'll have to be VERY aware and vigilant in keeping track of filters/sorters/etc that you apply throughout the flow of your application.
Re: the scale of your application's data, I would strongly suggest not trying to load all your model instances in at the same time (depending on the size and complexity of data, of course). Unless you actually need all possible instances available in the application at all times, I would adopt an approach that loads only what you need, depending on the scenario. If you need access to thousands of records, you can always apply remote filters to still deal with the whole data set on the server side, but only actually interact with a subset of the data on the client side.
Ultimately, I wouldn't worry so much about whether or not a particular approach "fits" the MVC pattern (which is itself a very particular flavor in Ext JS, a flavor not desired by everyone...). Yes, you want to create an approach that is extensible and manageable; however, I would argue that the requirements of your application should drive how you utilize the MVC conventions that Ext JS 4 provides, rather than allowing the MVC conventions to determine your business requirements.
Architecturally speaking, a controller does not know about view (usually) and it certainly doesn't know about some other controllers view. Controllers don't know about other controllers either. Sometimes it is necessary for these loosely coupled components to be able to communicate, but best practice is not to tightly couple them together. Is there a messaging framework plugin that allows different components to emit and receive global messages within the app? Is there a better way to handle these kinds of communications?
It wouldn't be too hard to create a pub/sub hub using something like jQuery.Callbacks. However, that is not part of a typical Ember.js app.
When something happens that needs to be communicated beyond the scope of the responsible controller, the pattern is to send the action up to the router, where the current state can handle it. The router/stateManager is the coordinator of the app, and can respond to the action by sending messages to other controllers and/or models, and/or by transitioning to another state.
I tried to diagram this in a talk I gave recently: http://www.lukemelia.com/devblog/archives/2012/08/23/architecting-ember-js-apps/
I'm still new to Ember, but wouldn't Ember Instrumentation be useful in this case? It allows to publish and subscribe to custom events. Great explanation can be seen in this answer.
I have some javascript objects that I'd like to collaboratively manipulate, but am having a hard time understanding the best way to achieve this in Meteor. These objects are NOT bound to specific collections, but rather live in-memory alongside the Templates that serve GUIs that are bound to collections.
I figured two things:
(1) Perhaps I should circumvent Meteor's native pub/sub stuff for this and simply leverage the existing SockJS infrastructure inside Meteor. I was able to get the SockJS URL from Meteor, but haven't successfully made a SockJS call yet. (I can provide more detail if need be)
(2) Or maybe leverage the existing pub/sub options in Meteor and use a Template as a shim to listen for updating. I looked here for that, but so far, haven't been able to iron out the kinks. Perhaps I should use a collection as a shim as well?
Again, these are NOT bound to collections, and I'd suspect vanilla SockJS or socket.io to be fairly straightforward on how to broadcast the changes. So, I'm struggling on how to incorporate collaboration in a Meteor app that doesn't originate with a collection being updated. I want to pursue one of the above, but would like to know which approach seems most feasible? Thanks for your help.
I guess there are two scenarios:
Things that need to be collaborated on I think should be persisted in a collection. However if there is a large amount of such data that is very transient and it really doesn't make sense to use a collection, it is theoretically possible to wire up a collection which uses minimongo (in memory mongo) on the server side rather than the real mongo driver.
The devs have indicated that it probably can be done, but AFAIK no one has actually gone ahead and tried it.
Things that don't need to be collaborated on should just be stored in the Session client side I think.
I ended up using the new constant block helper that was released with Meteor 0.4.0 to keep my out-of-Meteor-scope javascript objects from being manipulated by Meteor:
http://meteor.com/blog/2012/08/31/introducing-spark-a-new-live-page-update-engine
This lets me update these objects via a different means than Meteor.