I have a Vue.js component which gets a big list of releases from the database, at which point we can use all the lovely reactive list-filtering functionality to drill down to what we're looking for. The problem is that there's a very noticeable lag after page load before the list appears on the page.
Obviously loading the data in via ajax may not be instantaneous, but I thought I might be able to get better results by e.g. getting the data on the server-side with Laravel, and then passing it to the component from its containing Blade template as a prop. Not much luck so far though, again, a noticeable wait for the component to receive and display the data.
Are there any simple approaches for having a Vue component ready to go as quickly as possible? I looked at the prerender-spa-plugin for webpack but I don't know if that would interact properly with the Laravel routing. Likewise server-side rerendering with node seems like it could be more trouble than it's worth.
Has anyone experienced similar issues and found anything like a great solution?
you have too spot where you could do somethings. 1 on the server. by caching queries or somethings. And the second is on client side. when you handle the received / fetched collection. If you have, lets say 10000 entry, this would take sometime to a: parse the json object, b: create necessary vue components (if you're using vue component for row), and generating corresponding dom. So if you split and handle the recieved data in sized chunk. Vue would update the dom accordingly. and Fill the dom more like a stream. Not always the best approch but working in many case.
Related
Using Vue Js with Laravel I would like to keep open an expanded nav bar when the user refreshes the page (if they have chosen to open it initially).
The nav bar open/close status is stored in the component's data with a true/false boolean.
I'm a bit confused of which approach to take as have researched various options, so seek the best advice as a noob. Ideally there is a simple way to have the 'data' persist in my component rather than it getting re-rendered to the default of false! Therefore I guess it needs storing in the user's "session" state locally right?
But what do I use and how?
sessionStorage
localStorage
Vuex - https://v2.vuejs.org/v2/guide/state-management.html
a plugin - https://github.com/vuejs/vuex
Laravel session - https://laravel.com/docs/5.5/session
Thanks.
Vuex with a plugin such as this one if your application is large/is growing in complexity. Its a bit of a learning curve though so if you only have a few things to keep track of their states, then localstorage would be a good solution.
Localstorage has the advantage of being easy to use, widely adopted and if you need to in the future, it integrates nicely with state management systems like vuex. The api is quite simple, really just getItem and setItem for common simple use cases. It persists across browser sessions as well.
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Sessionstorage is roughly equivalent to localstorage with the key difference being once you close the browser, it gets wiped.
I have a long list that I want to let the user manipulate in a browser-based web application. Using jQuery, the most straightforward way would be to render it on the server as part of the initial page load, and include a small script that registers event handlers for AJAX requests and DOM manipulation.
In the case of VueJs however, it seems to me that the most straightforward way is for the initial request to load the page layout only, then call an API to get the data for the long list. In other words, VueJs renders the initial list, not the server.
While this is workable, I am hesitant to introduce this second request unless I really have to. Is there a more straightforward way to go about this? Am I missing something about how VueJS works? I would really like to render the initial list on the server side if possible. For example, would it be workable to somehow include the initial list as 'transcluded' content?
I don't want to have to get in to VueJS' complete server side rendering, since it looks like an advanced topic (and this is a simple task). I have experimented with passing the initial list data as JSON in the <head> of the page (inside tags that register it as a javascript variable), but that seems like a hack/workaround.
In the case of VueJs however, it seems to me that the most straightforward way is for the initial request to load the page layout only, then call an API to get the data for the long list. In other words, VueJs renders the initial list, not the server.
Yes, it is most straightforward way, and considered as anti-pattern also. Just for the reason in your next sentence: "While this is workable, I am hesitant to introduce this second request"...
I think you should read following post on medium.com first. It is about Vue and Laravel framework, but the principles herein can be considered universal:
https://medium.com/js-dojo/avoid-this-common-anti-pattern-in-full-stack-vue-laravel-apps-bd9f584a724f
I'm trying to figure out what is the best way to handle a quite commons situation in medium complex apps using Flux architecture, how to retrieve data from the server when the models that compose the data have dependencies between them. For example:
An shop web app, has the following models:
Carts (the user can have multiple carts)
Vendors
Products
For each of the models there is an Store associated (CartsStore, VendorsStore, ProductsStore).
Assuming there are too many products and vendors to keep them always loaded, my problem comes when I want to show the list of carts.
I have a hierarchy of React.js components:
CartList.jsx
Cart.jsx
CartItem.jsx
The CartList component is the one who retrieves all the data from the Stores and creates the list of Cart components passing the specific dependencies for each of them. (Carts, Vendors, Products)
Now, if I knew beforehand which products and vendors I needed I would just launch all three requests to the server and use waitFor in the Stores to synch the data if needed. The problem is that until I get the carts and I don't know which vendors or products I need to request to the server.
My current solution is to handle this in the CartList component, in getState I get the Carts, Vendors and Products from each of the Stores, and on _onChange I do the whole flow:
This works for now, but there a few things I don't like:
1) The flow seems a bit brittle to me, specially because the component is listening to 3 stores but there is only entry point to trigger "something has changed in the data event", so I'm not able to distinguish what exactly has changed and react properly.
2) When the component is triggering some of the nested dependencies, it cannot create any action, because is in the _onChange method, which is considering as still handling the previous action. Flux doesn't like that and triggers an "Cannot dispatch in the middle of a dispatch.", which means that I cannot trigger any action until the whole process is finished.
3) Because of the only entry point is quite tricky to react to errors.
So, an alternative solution I'm thinking about is to have the "model composition" logic in the call to the API, having a wrapper model (CartList) that contains all 3 models needed, and storing that on a Store, which would only be notified when the whole object is assembled. The problem with that is to react to changes in one of the sub models coming from outside.
Has anyone figured out a nice way to handle data composition situations?
Not sure if it's possible in your application, or the right way, but I had a similar scenario and we ended up doing a pseudo implementation of Relay/GraphQL that basically gives you the whole tree on each request. If there's lots of data, it can be hard, but we just figured out the dependencies etc on the server side, and then returned it in a nice hierarchical format so the React components had everything they needed up to the level where the call came from.
Like I said, depending on details this might not be feasible, but we found it a lot easier to sort out these dependencies server-side with stuff like SQL/Java available rather than, like you mentioned, making lots of async calls and messing with the stores.
On my website landing page, I am calling various AJAX actions.But the performance is poor as of now.These actions are
To get latest articles
To get latest news
To get latest Jobs
To get recent added users etc.
I am showing all this information in dashboards for each AJAX actions.
My question is,
From my AJAX actions, should I return the HTML or JSON? Which one would be better in performance and maintainance point of view?
I have following few points on these approaches -
HTML
Pros-
1. Will be easy to code
2. Easy to maintain.If there is any UI change in dashboard, with HTML it would be easy to do.
Cons-
1. Performance hit as complete HTML would be sent on client side.
JSON-
Pros-
1. Good performance as data transfer size would be less.
Cons-
1. UI change in dashboard would be comparatively diffcult as I need to change JS code rendering logic.
I want to understand if my assumptions are correct or not.And if there are any other points in these approaches?
Loading and embedding HTML directly as opposed to just sending the data and transferring it into a DOM structure client-side should not be so much different when it comes to performance.
Usually the greatest performance “killer” in an HTML page environment are HTTP requests – they take close to “forever” compared to all other stuff you do client-side. So if you have to pull data for multiple such widgets, it might be a good idea to encapsulate those data transfers into just one HTTP request, and have the different widgets read their data from there once its loaded. And for that, a data format like JSON might be preferable over HTML.
I have a very large webform that is the center of my Yii web application. The form actually consists of multiple html form elements, many of which are loaded via AJAX as needed.
Because of the form's size and complexity, having multiple save or submit buttons isn't really feasible. I would rather update each field in the database as it is edited by asynchrously AJAXing the new value to the server using jeditable or jeditable-like functionality.
Has anyone done anything like this? In theory I'm thinking I could set up an AJAX endpoint and have each control pass in its name, its new value, and the CRUD operation you want to perform. Then the endpoint can route the request appropriately based on some kind of map and return the product. It just seems like someone has to have solved this problem before and I don't want to waste hours reinventing the wheel.
Your thoughts on architecture/implementation are appreciated, thanks for your time.
In similar situation I decided to use CActiveForm only for easy validation by Yii standarts (it can use Ajax validation), avoiding "required" attribute. And of course to keep logical structure of the form in a good view.
In common you're right. I manually used jQuery to generate AJAX-request (and any other actions) to the controller and process them there as you want.
So you may use CRUD in controller (analyzing parameters in requests) and in your custom jQuery (using group selectors), but you can hardly do it in CActiveForm directly (and it's good: compacting mustn't always beat the logic and structure of models).
Any composite solution with javascript in PHP will affect on flexibility of your non-trivial application.
After sleeping on it last night, I found this post:
jQuery focus/blur on form, not individual inputs
I'm using a modified version of this at the client to update each form via AJAX, instead of updating each field. Each form automatically submits its data after a two seconds of inactivity. The downside is the client might lose some data if their browser crashes, but the benefit is I can mostly use Yii's built-in controller actions and I don't have to write a lot of custom PHP. Since my forms are small, but there are many of them, it seems to be working well so far.
Thanks Alexander for your excellent input and thanks Afnan for your help :)