I am working on a page which contain lot of different components and images. Each of the them have an individual Intersection observer instance to detect when they are visible.
I am curious to know if using multiple instances on a same page can degrade the performance. Is it possible to use single instance of IO api in the whole react app ?
Related
I'm wanting some advice/opinions about react component usage.
When faced with two different designs for the desktop and mobile version (NOT an app) of a site, do you use the same components and modify various parts using media queries or JavaScript window size etc OR do you create different components where required and render differently if it's the mobile site?
Any strategies you have used with your experience/opinions on would be of great help. Many different ones will be appreciated!
Thanks!
I would use the webs standard of responsive design and libraries like bootstrap or foundation. There is no need to write different views unless you are targeting different platforms (native vs web for example). This will save you time and effort as the gains you get from writing different components are not substantial.
That said if there are particular pages that would be better served with completely different UI you can do a mix of both. There is no advantage in simply creating two home pages that have a bunch of text, this issue has been solved by responsive design practices and not taking advantage of them is a step backwards.
Also take advantage of component re use as much as you can. If desktop shares 5/6 features write the 5 in a way they can scale differently to be shred and write two versions of the 6th.
I wouldn't say that the two options are mutually exclusive. Take advantage of responsive design practices when you can and take advantage of the componentization of react when you can. If you ever find yourself not sure which way to go it likely means use responsive design (IMHO).
I have designed apps where the target was truly different platforms. We wanted to have native and web side by side. What you are looking for is a middle ground as many components will likely be shared but a handful may require different functionality and thus components. I have seen two app structures, one that organizes your app by type (components vs containers for example) and another that organized code based on page structure (index, account, login, shared). I have found that when needing to mix components that accomplish the same function but target different platforms its best to separate by page structure as in the index page I can simply have a iOS index and a web index side by side when needed. This allows me to have two stateless components and one stageful container to power them. This also makes more sense mentally for larger apps and allows you to do more of what you are looking to do.
Overall, if you are needing to use if statements to hide and show functionality consider breaking things down into reusable components and create a mobile and desktop presentational component being powered by a single state full component.
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.
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.
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.
There are a number of popular frameworks around to provide data binding between objects and views. This is a great idea; when the data changes, the view is updated automagically and vice versa. However, in mobile web apps, wrapped with Phonegap or equivalent, the app usually consists of one single html page holding multiple "views" (usually divs used as containers). Only one view is displayed at a time, which means that only data bindings belonging to the current view need to be calculated and updated. If all views are updated all the time, it means a lot of unnecessary calculation and updates of invisible DOM elements. This should be avoided, since performance often is a problem in these apps.
What is the case with current JS frameworks? How do they handle this? I am especially interested in Angular.JS, but if there are other frameworks that handle the issue better, I am very curious to know.
You can try knockout.js. Knockout allows you to data-bind subset of elements on your page