We have an Angular single page application that loads fairly fast. However, there are data components in the application that load (and render) asynchronously. I've looked all over the web and it seems like a fairly common problem, but without a good solution. Are there any tools out there that can perf benchmark just a component of a page, rather than the entire page? And we need to know the time between the request made for data and when rendering that data is completed.
Try the open source Chrome plugin Angular-performance, you can benchmark specific controllers, digest time and events in Angular applications: https://github.com/Linkurious/angular-performance
Any chance of getting a reference to that particular view?
Similar to React + Flux, I believe Angular would be classified as a "current-state" front-end framework. Because it's functional programming and not object oriented. This is the reason company's have in the past switched over to angular, because of the speed and asynchronous nature of javascript.
If there are certain elements you don't want the DOM to render until conditions are met, I would recommend looking into ng-show and ng-hide.
https://docs.angularjs.org/api/ng/directive/ngShow
I hope that helps? I am not sure what situation in particular you don't want rendering asynchronously? Let me know how I can help.
Related
I need to keep the state of a component A in cache, so that when I navigate from A to B or C and I come back to A it does not get re-render again (it also includes a API call in its constructor, so it's kind of slow). I will like to keep this initial state through out the whole session of the user.
In Vuejs https://jsfiddle.net/shidianxia/ckj7xbqq/ they have a very simple way to do this using this syntax:
<keep-alive :include="include">
<router-view></router-view>
</keep-alive>
I will like to have something similar for AngularJS, notice I say JS so old angular. I have an hybrid application using modern angular but keeping old angularjs router.
I appreciate your help, thank you.
According you your comment I think it would make sense to build it in 2 parts.
Part 1: Keeping the state in a service
By keeping the state in a service you would limit the request send to the server and thus saving time.
Part 2 Using $templateCache
By using angularjs template cache service you should keep the time for rendering the view with your data to a minimum. You can find infos on how to use that in their docs https://docs.angularjs.org/api/ng/service/$templateCache
If you in the end still have this flicker while rendering you should use ngCloak to prevent showing the uncompiled view (https://docs.angularjs.org/api/ng/directive/ngCloak)
This is more of question of if it makes sense to use Reactjs in my instance. I have an application that generates html serverside. I can not use any js based templating solutions serverside, it is a java/jsp solution blackbox.
Since the markup is already defined I am weary of using JSX to duplicate all the template logic currently only on the serverside. What is typically the best approach to integrating reactjs in to an application like this.
What will be the real advantage to using reactjs for me in this situation. Most of may app will continue to be rendered serverside go forward.
Obviously React is not designed to be used like this; but you could still do it.
Long story short: If you want to build something more complex in front-end you should do it; if you only want to get advantage of JSX templating instead of jsp, it's just a big overhead.
Advantages:
You will be able to step away from standard jQuery approach of handling javascript in .jsp.
You will get all the benefit of a client-side framework, so you are able to handle more complex scenarios in front-end as you would do with standard javascript.
You could hide some business logic in the java side (servlets) and making it available to React world.
Disadvantages:
Probably it's a pain to prepare the development environment mode (webpack, hot-reload, etc.); e.g. you'll need to recompile the jsp on the fly on every js change.
You can't use client-side routing (so you'll have like one SPA per page).
Probably it's really hard to make server side rendering work (for the React part)
The actual loading time of a web page and the user impression of that loading time can be quite different. For example, here are three different experiences a user can have while a page loads:
Waiting for a blank page to completely render at once
Parts of the page immediately render (e.g. top navigation) but components load
individually
The entire page is made of components that load individually
These different UI experiences become more common as JavaScript frameworks become more common, such as React or Angular.
The user's UI experience can also change if individual components use loading markers to indicate something is happening, such as Loading... or a spinning wheel.
What are some guidelines for improving the user impression of a fast loading page? If there are not any, how do you approach this problem?
There is always going to be an initial hit whilst the javascript gets parsed and executed. However, if you are after very fast initial loads you could try a few techniques such as:
Delivering a "critical" payload first which will quickly load the "essentials" of your webpage to make it feel much more responsive. Webpack has a code splitting feature that you could use for this effect.
Making use of Server Side Rendering (i.e. universal style applications) which will execute the javascript server side and embed the output in the HTML payload. This probably renders the best results for what you are after as you don't getting the "flashing" parts as much you would otherwise. It's a pretty cool technique but is probably presents more technical challenges so you will have to decide on your own tradeoffs.
If you are after an example of SSR you could look at a boilerplate I recently put together for React: https://github.com/ctrlplusb/react-universally
In that boilerplate I actually also make use of Webpack's code splitting feature based on the Routes defined within the application. Checkout webpack's docs on this: https://webpack.github.io/docs/code-splitting.html
If webpack is completely new to you I highly recommend the survive js series: https://survivejs.com/
I know what angular.js is and I even had a question about it #Why use AngularJs in frontend if Laravel is already used as backend?.
but recently I started to read about React.js and from its site (its the V in the MVC) which is exactly what am after "handling the view and nothing else".
for me, I think Angular.js as an MVC framework was made to be used with something that is built with JavaScript from start to end like Node.js
and it seems like an overkill when used with something like Larval, where I simply need something to handle the frontend and nothing else + Angular have 2 main drawbacks
with the latest news about a new version that won't have back compatibility with the current version makes me even feared to start learning it just to find that more or less every project out there is using the old version which mostly is true.
angular renders the whole dom if anything got changed which again is an issue for big projects.
so based on the above, plz note that I want to learn/use JS solely to enhance the user experience not to build another Gmail or Facebook and so my question is,
could React.js be used with Laravel to handle the view and do everything Angular was going to give, or I have to use Angular liked or not?
could React.js be used with Laravel to handle the view and do everything Angular was going to give?
No
React is just for views. React components are stateful components with some really clever rendering stuff happening behind the scenes. To build a fully functional front-end app, you'd need to tie in some other code (or write it yourself).
React works well with Facebook's Flux architecture. I would suggest looking into that to learn how to manage the state of your react components.
What's key to understand here is that Flux and React are not parts of a large front-end framework. React is a library and Flux (as provided by Facebook) only provides a Dispatcher. The rest is up to you to implement. There are some pre-existing implementations you can look at if you need some help to get started.
What I like about flux is that it allows me implement things the way that fits my application best. React takes care of the heavy DOM lifting and is very easy to learn. Compared to Angular, I don't have to learn arbitrary conventions and gigantic APIs of a huge framework.
I have Backbone working with pushState. It's very nice, but now I understand that I should support loading the app from any route that backbone uses. For example, if somebody enters a backboen route manually to their browser, the server should respond to that and render the page and then let backbone take over.
What I am wondering, is what is the most efficient way to handle it? Backbone recommends also bootstrapping data on initial page load to reduce ajax requests. Should I only try to bootstrap data that is necessary for that particular view or should I try to bootstrap basic collections (for example: users, settings, documents, etc)?
For the first part of your question, you could just specify a callback route (which matches everything and gives the homepage) so the user never gets a 404 (don't use that when developing the app though, it could give you some hard times debugging it if you have a real 404 when making a call to the server).
For the second one, I'd say it depends on the amounts of data you need. I'm personally developing a modular application, and unfortunately can't really bootstrap anything. I'd say it's just some advice.