Can I use web worker for ui components? - javascript

I am getting my head around to understand serviceWorkers, web workers and indexedDB. I understand their usage in a web application. I have 2 questions.
I am developing jquery widgets like color picker, date picker, token field, etc... Is it a good idea to use indexedDB to cache data retrieved from server for libraries like tokenfield, combobox that has data fetch from the server?
I am planning to use web workers for these libraries but am not sure whether this is feasible. Have any other uicomponent providers like Bootstrap tried using web workers? and what could be the issues I will be facing?

Usually, workers are used for a big calculating task (for example for parse file in the background without blocking main thread and hence UI), working with a network (into service workers it is possible to catch network requests and return something without going to server - it is useful for PWA). I think that using workers for storing data from UI components like color picker throw worker to indexedDB is redundant. Usually, this kind of data is not very important and sensitive, hence the best choice to store it - local storage.

Related

Use NuxtJs on server-side to Hydrate a Cordova client

I'm trying to upgrade an old mobile application written in vanilla Javascript+React hosted on Cordova. This application leverages a simple api on the server-side:
when the app requires a page, sends a request to the server
the server elaborate the request, fetch the resources, and then reply with a complete HTML+JS. The Javascript is a ReactJs view compiled with Gulp/Browserify
the app takes the reply and stores it in a local Sqlite DB, then mount the received code and the view become reactive.
if the user requests a view but has no connectivity, the app search though the Sqlite db wether there is a cached view and uses it instead of requesting a fresh copy from the server.
When developing, the React JSX code is immediately compiled to a vanilla JS so, when in production, the api only needs to merge the vanilla JS with the HTML template. Plus, adding new features and fixing bugs is quite easy, because each user essentially download any updated view, each time he enters in it.
The problems with this approach are:
developing is painful because of the continuous compilation
a "base" part of the application resides on Cordova assets (basically the utilities to fetch from server, caching etc) and fixing this parts needs a new app release or ugly override patches
the caching feature often causes problems to the Sqlite database (which is used also for other stuff on the app); as a result, the DB sometimes corrupts and the user must clear the app data.
we would like to get rid of React
We already used NuxtJs for generating static sites, and it's great, but in this case I cannot leverage the SSG because the app should be almost completely served from the api, so we can keep the easy-feature-and-fix stuff.
I never used NustJs SSR and wonder if could be suitable for my use case, for example, could I spin up a NuxtJs instance on server-side which generates the html output and hydrate a barely empty Javascript client on Cordova? Is there a better way to accomplish this task? Should I use only Vue instead?
Thanks

Storing and Managing offline data in Web apps

I am creating a web app that allows user to upload some data to the web server. But I want this app to work offline as well , so if network is not availabe it should store the data in local storage and it should push the data to the server when network is available.
Is there a JS library that could simplify this?
The feature you're looking for is the Background Sync API.
You could use workbox-background-sync to make usage easier, including a built-in polyfill for the behavior on browsers that don't support the Background Sync API.
JsStore is a client-side javascript library for performing database operations inside the browser using indexeddb. You can check that.

NodeJS-App - DOM manipulation?

so I have my NodeJS-App, which recieves Data via Serial and also provides a little http-server to display some HTML.
Now I need to manipulate the outputted DOM in real-time, depending on the Data NodeJS recieves. What would be the best practise for that? Should I use Websockets for communication between NodeJS and the DOM? Or am I completely wrong?
I am currently doing something similar. I am currently using jquery ajax GET and POST requests to handle it. while webrequests would work, its not realtime and does not update other clients if one client changes something. For realtime i would research into intergrating socket.io as it is realtime. the exact method of doing so would vary based on your specifications and your current setup. for instance if you are using express.js to handle the requests, it would be easier to intergrate than say native node.js. if speed and wait time is a factor, look into react.js to speed up the update process on the client side without reloading the page.

What's the best way to constantly watch for any changes on JSON using Angular?

Through the following code, I'm loading JSON once:
$http.get('/data').success(function(mydata) {
$scope.mydata = mydata;
});
I would like to watch for any changes coming from JSON and then reload the new data so I can update the $scope and consequently the view.
I could use a JavaScript setInterval function to reload every 1 second but that seems a bit nasty. Any better solution? Perhaps something written in Angular itself?
I'm going to go ahead and make the assumption that what you're after is real time updates in your Angular application. There are quite a few different options these days that enable real time updates on the web but unfortunately $http is not one of them. Nor is any technology built on HTTP (the protocol) as it is inherently request/response based and doesn't support persistent connections.
Depending on your server side technology you could take a look at something like Socket.io (for Node) or SignalR (for .NET) as they offer nice abstractions over top of raw Websockets. There are also some great services out there that make real time web very easy to implement. One of the best ones right now is called Firebase. They were recently acquired by Google and have native angular bindings so that realtime push notifications are available directly in your controller scope.
If you don't own the server you're making requests from, unfortunately you're going to be stuck doing HTTP based polling on a timer. Be careful that you don't poll too often as you might create a performance hit for your clients or exceed API limits on the backend you're communicating with.
Long polling using $interval is one option
Another option is to notify clients of data updates using WebSockets

How to create temporary files on the client machine, from Web Application?

I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?
You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.
You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).
You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.
If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.

Categories

Resources