A client has tasked me with refactoring their React app to support multiple screens. I have some ideas on how to approach this, and would like to get some feedback to see if I am on the right track.
The problem:
We have a relatively complex React app, and the client feels that splitting the app across multiple windows will make for a better UX.
As example of this split-screen set up, imagine that window 1 shows some data, and window 2 contains UI elements that allow you to filter that data. In this manner, the app is split across 2 windows.
(The 2 browser windows is a hard constraint imposed by the product owner. Other options like grid layout managers are not considered.)
The solution (so far):
We need to share state across two browser windows. To do so, we can use:
Local storage to keep track of state and use StorageEvent listeners to coordinate state changes between the two windows.
We can also use some of the web APIs designed to pass data between windows including: shared web worker, broadcast channels, and window.postmessage(). I learned about these in Blake Zimmerman's presentation here, PDF ~2mb.
This framework - neo.mjs, which uses web workers. I would rather not abstract the low-level details to a framework, because I am not familiar with web workers myself yet.
The question:
Is there something I am missing? Are there other tools I can use to share state between windows? Any good articles I can read?
I am also having trouble visualizing how to structure the React app to account for multiple displays. The best I could come up with is something like this:
<Main>
{isComponentAShown && <ComponentA/>}
{isComponentBShown && <ComponentB/>}
</Main>
where isComponent_X_Shown dictate which components the browser window should be displaying at any one time. These boolean flags will be part of the state shared by the two browser windows. Is there a better way to organize the App layouts to account for dual screen?
Thank you!
Related
I am learning React.js and new to web programming. All along when doing my own projects it's only for my own use, and hosted on localhost:3000. (i.e. one user).
I have a question about multiple users which I don't know if it's specific to React or just general web programming, but I can't seem to find it online, as perhaps it's too basic? And sorry if it's a very basic question. I will have to make an app for internal use for a team of less than 10 people soon, and it will be hosted on a local server accessible by this team.
Would the code be any different in terms of how I write this app? (say, it's just a todo list where users are able to add and remove items)
Specifically, how do states work when there are more than one user? Are they stored on the user's local device?
If one user clicks a button and sets some state from true to false for example, does it re-render for the other users too? Or do all users get their own instance of the app?
I would also appreciate it if you would know what kind of resources I should look at for this question, as I would like to read more in-depth about it.
well, all the apps run on each user own machine independently. State, actions and all other(whole app) are happening only one user own machine. So there is no interaction if I may say so out of the box between different machines(users). You may achieve that with help of some sockets connections( for example instant chat)
I have this project where I have to code a website and ios and android apps.
I have to do this with a very limited team (basically myself). So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
I have come to consider flutter : the logic (and interaction with the backend) in dart can be compiled to both ios and android, and to javascript for the web site to call. I also like how the UI is built using flutter.
For the web site, I know there is flutter web that can be used to do a web app, but I want my website to feel like a web site more than a single page app. I have thought about using React+Gatsby to do the website's ui, while calling the dart compiled js for the logic. That would enable high page loading speed, good seo, while keeping the interactivity of a react app and the single codebase logic through dart to js compilation.
I am wondering if this seems like a good approach to you, and if not, how you would do it.
In this approach, I am wondering if it would be possible to embedded flutter web widgets inside of react js components, always in a concern of maintaining as low platform specific code as possible. I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
Update
Flutter Web is now available in a stable version for production.
Below answer is relevant back to the time when question was asked.
Flutter Web not recommended
At the current date, I would recommend not to use Flutter Web for production as it's in Beta. The Flutter Team is still working on improving quality, performance and browser compatibility. You must be cautious about using it as you may run into bugs and some other complications.
Also, I believe that the community support for Flutter Web might be on a lower side as it's pretty new.
Limited browser support
Another factor which bugs me is that the Flutter web apps can run on limited browsers as of now which would affect the reach to your user base:
Chrome (mobile & desktop)
Safari (mobile & desktop)
Edge (mobile & desktop)
Firefox (desktop)
What would I prefer?
Well, although it might be a hassle to handle different codebases for mobile and web platforms, I would still prefer to stick with React JS as it's much stable with better browser & community support as opposed to Flutter Web.
Good luck with your app! :)
I am unaware of how to use Flutter widgets inside a React app. But to address your other concerns,
So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
Given no other restrictions, this leads to a single Flutter app for both web and native. For a team as small as three we still found it easier than having multiple projects.
The key factor in merging our initial projects to one was the notion of mobile browsers. In a mobile browser you website should reduce itself to the look of your mobile app, unless they have different purposes. And this automatically happens with Flutter projects if you derive your layout breakpoints from screen size. Otherwise you would code your same narrow design twice: in Flutter for native apps and in React for web.
Same goes for native apps for tablets in landscape mode. They call for a layout that resembles your desktop browser version, and you automatically get it with Flutter.
Also in web version you may have more tools than in a native app, just because your screen allows it. Naturally, you would code this logic in JS. But then you get an order to migrate this to native apps. Would you then replace your JS logic with Dart logic compiled to JS and embedded into frames? This is a messy road.
Lastly, think of Mac, Linux and Windows platforms that will come to Flutter soon. Should you ever need a desktop native app, you would want the same layout as with web.
I want my website to feel like a web site more than a single page app.
The difference in feeling between a website and a single page app lies mostly in state management and URL handling. You may do the following to reduce it:
Introduce URLs for your pages. By default, in Flutter every piece of action can happen under a single URL of example.com/#/. The window then feels fragile as there is no URL to copy and get back to. Flutter's Router API, released in Oct 2020, allows you to generate URLs on any change in your app's state and parse the state back from URL. If you do it right, then everything on your screen becomes a function of the URL, just like in traditional websites.
Use url_stragegy package for your URLs to be example.com/path rather than example.com/#/path which immediately feels fake.
I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
No, it does not. Mostly because you get too narrow a channel of communication of messages between JS windows. How would you listen to Flutter's BLoC's stream in another frame? It would take too much boilerplate code. Also I cannot think of easy debugging process.
To me, Flutter Web still has drawbacks:
It takes awhile to load.
Many specific JS APIs are not implemented yet.
Many services you integrate with may not have Dart SDK, while having JS SDK. For instance, I struggled to get Ably working.
No search engine optimization.
You cannot use em as a screen unit, so scaling elements may get tricky.
Still with limited resources a single codebase outweights everything else.
To be clear, my team has been working on a web+native project the whole 2021. It now has passed most of the testing, but not yet released. For a sense of scale, it is a marketplace of 40+ screens.
My website is built with Angular2. Imagine it as a big dashboard with a lot of modules. Sometimes information from multiple modules are required at the same time - therefore I want to allow my users to open a module in a new window. A real-world example for this is the video container of Hangout.
From my research there would be 2 ways to do this:
I open the route of the selected Ng-Component in a new window. As a result angular would reinit all services. To keep my data consistent I would need find a way to sync the instances. Maybe some kind of service that writes all attributes to localStorage?
This is somehow the way GoldenLayout implemented the Popouts.
I could init my component in window A and hide it - Now open a new window (B) and pass a copy (Css, HTML, Data) of my component to it. This would mean that I only need to sync the mirrored component, but I am not sure if this is good architecture.
Which way would you go to solve the described problem and are there more elegant solutions?
Learning a little React currently. I'm finding myself confused about some of the utility here. One sticking point that seems to (for me, at least) undermine it's value is that If I want to sync my UI to data residing on the server (which can and will change), I need to manually poll the server? Aside from component-based architecture, I'm not sure how this is getting me further than well structured and logically implemented AJAX. Even in the React docs, they're using JQuery in this regard. https://facebook.github.io/react/docs/tutorial.html#updating-state
I'm sure I'm missing the forest for the trees or whatever.
Thanks!
React is (citing their page)
a javascript library for building user interfaces
The main focus is to build a view layer for your application. This means you have full freedom in choosing what to use to fetch your data. For simple uses it can be jQuery or fetch.
It's generally recommended to not fetch data directly in your components and use one of Flux pattern implementations, e.g. Redux.
If your application has to be constantly powered by new data from server you can think about using something like RethinkDB on your backend and connect it to Flux store on your frontend.
We are designing a complex web app which runs in multiple browser windows .will use AngularJS
(note it has to look/feel like one app – just that it is spread across several browser windows)
Javascript allows a parent window to reference the objects on other windows as long as the parent retains references to the other windows. Those objects can be accessed either by the native accessors or, for example, by jQuery.
Is a multi-window app something that's been done with Angular before? How would such an app be structured to be scalable?
(I have seen the big 'angular-app' reference app which is a template for large scale apps (if I could only get it working!) but haven't found anything on using multiple browser windows...
Probably not the answer you're looking for, but from my experience w/ AngularJS it seems what you are looking for in an anti-pattern for angular. Specifically, angular is big on scoping - so a controller and view would only 'know' about its own stuff. Any other controllers/views on the same page, or other windows, etc. wouldn't necessarily have references to each other. Rather, an application on a page would have a $rootScope which can serve as a message bus w/ $emit(), on$().
So, perhaps look at this as loosely coupled parts with a centralized message bus that figures out which windows get what events. Then each part (app/controller/view) is just responding to those events.
Note: We had a test app that simulated multiple UIWebViews in a mobile app by hosting each angular app in and iFrames and used this approach successfully. Very composable, very testable.
HTH