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
Related
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.
In AngularJs I can do this:
<header data-ng-include="views/header.html"></header>
which AFAIK asynchronously downloads views/header.html from client and interprets it as a template.
I want to ask if there is any sane motivation to use it because all I encountered with this was a pretty bad usex experience. I have a black Twitter Bootstrap header and this causes the header to show a moment later and therefore "hits" the user right in the eyes once all other content is visible.
On the top of that it does the request every time eventhough it just for a 304.
You can use an ng-include to separate some HTML that is re-used, you can also bind the data-ng-include to a variable on your scope and change the view similar to what you get with ng-view and using the $routeProvider configuration.
I'm not entirely sure about the attempted reload and seeing the not modified response. I would assume ng-include would operate under the same caching rules as a normal page but perhaps something is different since it does an AJAX request for it I assume.
I think you should be able to make it sync loading by adding a public counter to the on-load property of ng-include. And you can then wait the counter to increment to be the number of the templates loaded by ng-include, and then after all templates are loaded continue with other logic.
There are definitely some advantages of using ng-include. For example, you can use it together with ng-switch to conditionally load a template. And it also automatically creates a child scope if you want to isolate model from the current scope.
Hope it can shed some light on.
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 :)
Background
I'm working on a web application utilizing AJAX to fetch content/data and what have you - nothing out of the ordinary.
On the server-side certain events can happen that the client-side JavaScript framework needs to be notified about and vice versa. These events are not always related to the users immediate actions. It is not an option to wait for the next page refresh to include them in the document or to stick them in some hidden fields because the user might never submit a form.
Right now it is design in such a way that events to and from the server are riding a long with the users requests. For instance if the user clicks a 'view details' link this would fire a request to the server to fetch some HTML or JSON with details about the clicked item. Along with this request or rather the response, a server-side (invoked) event will return with the content.
Question/issue 1:
I'm unsure how to control the queue of events going to the server. They can ride along with user invoked events, but what if these does not occur, the events will get lost. I imagine having a timer setup up to send these events to the server in the case the user does not perform some action. What do you think?
Question/issue 2:
With regards to the responds, some being requested as HTML some as JSON it is a bit tricky as I would have to somehow wrap al this data for allow for both formalized (and unrelated) events and perhaps HTML content, depending on the request, to return to the client. Any suggestions? anything I should be away about, for instance returning HTML content wrapped in a JSON bundle?
Update:
Do you know of any framework that uses an approach like this, that I can look at for inspiration (that is a framework that wraps events/requests in a package along with data)?
I am tackling a similar problem to yours at the moment. On your first question, I was thinking of implementing some sort of timer on the client side that makes an asycnhronous call for the content on expiry.
On your second question, I normaly just return JSON representing the data I need, and then present it by manipulating the Document model. I prefer to keep things consistent.
As for best practices, I cant say for sure that what I am doing is or complies to any best practice, but it works for our present requirement.
You might want to also consider the performance impact of having multiple clients making asynchrounous calls to your web server at regular intervals.