in my app I'm showing a big table of data.
And as always I'm saving all the data i need to display in the $scope variable.
The problem is, with that much data in the DOM and also being watched by angulars digest loop the site lags a lot. Because I'm just showing static data, that can't be manipulated i would like to have a static scope that can not be manipulated on that very view and performs better.
So my question is, is there something like $scopestatic?
Your performance problem most likely comes from too many data bindings. If it's only static data, you need to get rid of that.
I suggest you use a directive instead, creating DOM elements from your data. You only need to do it once and your website should perform much better without so many useless bindings.
What you actually need should be bindonce
Another problem may be that showing a big table directly to user sounds like a bad idea. Human brain can not process too many datas. We can filter or paginate them for user instead.
Related
My situation is that I have multiple SVG templates that have data binding on my Angular project, and I want to somehow be able to determine if the data that is going to be bound to these areas is going to fit or not (not get cut off/cover something else basically),somehow mark the products(the data coming in from the angular service) to symbolizes which template it best fits into, or even write/modify the template on an individual product basis and save a copy for each product that I could have the component reference instead.
I am partly able to do this with some basic jquery within the component checking the natural width and height of objects coming into the templates, but it REALLY slows down page load, so it's not viable
I came to the conclusion that I should use a custom webpack to do this, possibly write a loader that analyzes the data coming in from the angular service and figure out which template that specific product fits best. The loader could do the calculations to figure out what fits where.
The reason I want to do this in the webpack is because I ultimately need to do the calculations anyway, and it would really bog down the load time to try and do this much logic dynamically on user load, not to mention it's just redundant in my situation to figure this out more than once, as the product info will not change until the website is updated with a new API call anyway.
I currently have a property hard coded that indicates which template to use(a number corresponding to a template), but doing it this way limits the scope of possible templates, and opens up many possible programmer goofs, as well as the fact that it doesn't cover smaller issues that ARE noticeable, and becoming a problem.
So, my question has three parts:
Is it possible to call an Angular Service/API call in general within a loader.js/ts file?
Can I manipulate the data coming in from an Angular Service/API call and have it preserve those changes (changing a flag property of each product coming in from the service)? The interface in angular that handles the data coming in has an extra property that I could assign potentially in the webpack to denote which template to use.
Could I write html files to a folder on the local project/to a database using that data from a service and the base templates?
I apologize for the wordiness, but the situation has a lot of unique parts that I feel are necessary to include. I don't need code examples so much as I just need to know if Webpack/Loaders can/should even do this. I'm obviously open to any suggestions as well as to other ways to solve this problem.
Notes:
All the code I really have so far for the webpack would be configuring my angular.json to run off of a custom-webpack.config.js file I created, it doesn't currently do anything.
The service executes an http request and is subscribed to by angular components that consume it's data, but I could possibly write a js promise and recreate the interface for the scope of the webpack/loader, which is why I think it may be possible.
I have been reading about how to correctly update views in Backbone.js by calling the render function when the data in the model changes and not by using lots of JQuery updates etc. This stops state and data being stored in the view and also spaghetti code later on.
My question is, is this a strict rule? I can imagine situations where re-rendering an entire view to show an error message next to a field is overkill, especially as it's not modifying state or data. What is the suggested approach?
There is no one recommended approach for everything, it depends on the specific situation. Especially for more complex views you might want to listen to specific events on the model and update/refresh just part of your view, (for example this.$('.myTextFieldCnt').addClass('invalid');.
If you find that you are doing a lot of these refreshes you might want to take a look at Backbone.stickit which is a backbone plug in that adds data binding to Backbone that can make a lot of these kind updates a bit cleaner (and helps you avoid some that spaghetti code).
Note: Sorry for the length of the post, but the reason I decided not to break it down in separate questions was because I find these issues hard to address without a complex problem like this. I am dazzled, and a bit afraid, that I'm trying to force Angular to do stuff for me which is not the 'Angular way'. Any advice would be highly appreciated, and would probably get me on the right track with Angular.
My problem is as follows:
I have a dynamically generated form, controlled by myFormCtrl. I want to go extremely modular: I want to use it whenever and wherever. This means, that sometimes I'll need to put it somewhere as-is, sometimes I need to nest forms dynamically (like when I change a form value, and other sub-form appears), or control two separate forms as one in a view by a parent controller, with one 'Save' button for both. The myFormCtrl uses $scope.type_id and $scope.rowid to know, which record should it display from the database. The records are then Ajax-fetched by a service, and saved under the myFromCtrl's $scope.formItems. When saved, the form sends back data to the server (via service) with the type_id and scope credentials, so the restful api knows where to put the record.
In theory that would be really easy to do in Angular.js.
It definitely would be in every object-orientated language: The parent class could call a public method of getFormValues() of myFormCtrl. Now that can't be done in Angular: parent can't read children's scope.
For me, it seems, that this is not a simple 'how to communicate between controllers' issue. I know that the answer to that question is services, events, scope inheritance.
Also, a number of other problems seem to emerge from each solution I found sofar.
So I have a myFormCtrlBase class, which does basic stuff, and other more advanced classes extend this one. I also have a formControls.html, and a formLayout.html partial. The first contains an ng-switch, and gives the appropriate input element based on $scope.formItem.controltype, the second has the html layout of a common form, ng-including formControls.html at the right places. It utilizes ng-repeat="formItem in formItems", so that's where formControls.html's $scope.formItem comes from.
When I want the form to have a different layout for example, I create a customFormLayout.html partial ng-controlled by the myFormCtrl class.
First question: what if my form layout can't be put in an ng-repeat?
Like when form elements need to be placed scattered across the page, or form layout is not something which could be fit in an ng-repeat loop. my formControls.html still expects a $scope.formItem to work with. Easy OO solution: parent puts formItem in child's scope.
My solution: I created a <formItemScopeChanger formItemScope="formItems[1]"> directive which gets formItems[1] as an attribute, and turns it to $scope.formItem variable. This solutions feels messy: directives are not meant to be used like this. Doesn't seem very Angulary. Is this really the best solution?
Second question: Is ng-init really that evil?
Say, form is not put in the view by $routeProvider, but in a custom partial: rent-a-car.html. Here, I want to have a form where the user can select a car, and an other form, where I get his contacts. The two forms work with different $scope.type_id's, so there need to be two different forms:
<h1>Rent a car!</h1>
<div ng-controller="myFormCtrl" ng-init="type_id='rentOrder'">
<div ng-include="'formLayout.html'"></div>
</div>
<h2>Your contact information</h2>
<div ng-controller="myFormCtrl" ng-init="type_id='User';rowid='{{userData.rowid}}'">
<div ng-include="'formLayout.html'"></div>
</div>
Angular docs sais, that the only appropriate use of ng-init is when aliasing ng-repeat values. I don't see what the problem is with the example above - it is still the cleanest solution, isn't it?
I use the same technique with nested forms - I put a controller in with a template, initialized from the html by ng-init, and shown/hidden with an ng-if condition.
BTW, this is the only real initialization technique I found beside writing a new controllers (extending myFormCtrlBase). In an OO language, parent would write into the child's scope and then initialize it.
Perhaps my approach is influenced by my previously used languages and programming techniques, and is absolutely wrong.
Some would say, 'get init values from parent scopes!', but I can't seem to understand how that would be safe and efficient. I'd need to do $scope.type_id=($scope.type_id || $routeParams.type_id) with every scope property, which is first: really not nice to look at, second: is risky. Maybe this is a single form in a simple template, but somewhere in the scope hierarchy, there is a possibility, that it will find a completely different type_id. Perhaps it will be a completely different controller's type_id.
I don't see how using '.'-s in my scope variables would help. I has the same risk as I see it.
Third question: how to handle rentACar.html submission?
When hitting a Save button on my rentACar.html page, the rentACarCtrl (the controller in charge of the model of the view) should somehow retrieve the values of the two forms, and handle the validation and submission. I can't seem to understand how the common mantra 'controllers communicate through services' would be applicable here. A service for only to these two forms?
Am I on the right track? Every one of these solutions seem quirky. I feel lost :)
+ 1 question: Even after all this hassle, I can't seem to find a good reason why Angular wouldn't let parents call children's public stuff. Is there a good reason? Most of the above problems would have an easy answer in every true OO js framework.
You need to think about how you would test the logic of each of these components. Ask yourself how each of these 'features' work in isolation.
A few tips to help get you back on track:
Try and say away from a 'base' controller, I have hit many dead ends with scope inheritance, the logic gets muddled and hard to follow. Also this affects testing, because you find yourself having to stand up more objects than should be necessary for a test
Favor a singleton (angular service) for shared state over scope inheritance (a parent controller)
Create a directive and bind to the shared services state before using ng-include (prefer interacting with a service over scope inheritance)
Use an event pattern when another service or controller needs to now about events triggered from directives. A shared service (state) can listen for those events
What your asking is quite complex and I would like to help, Try to focus on one feature at a time and provide some code, I can show you how to use a shared service and the event pattern once you provide some examples
Also, taking a test first approach will often reveal the best 'Angular Way' of doing things.
Thanks to Mark-Sullivan, and a lot of work, trial-and-error attempts, the whole thing has boiled down to this. I'd like to get feedback from Mark, and other Angular gurus about this. What do you think?
You don't do class/prototypical inheritance in Angular.js. It is hard to test, and thats a big problem. For those, who are looking for 'inheritance' in Angular, I recommend this:
Your base class is the controller. The controller is an abstract model anyways, so it is perfect for that purpose. Use a $scope.init() function in your controller, but don't call it from there!
If you want to 'extend' your controller's functionality, use directives. In you directive link() function, call the controller's $scope.init(). (when compiling, angular runs controllers first, and directive link functions after). If scope had a $scope.name='base', in the directive link you will be able to redefine $scope.name=child, and after that, run $scope.init().
But wait! But this only allows a single-level inheritance. - Yes, thats true. But if you are looking for multilevel inheritance, you should use Services.
Multilevel inheritance is nothing else, but sharing the same code in a hierarchical class structure. For this purpose, use Services, and throw in these services with the dependency injector into your directives. Soo easy. This should be easy to accomplish, easy to understand, and tests run smooth.
Directives are very powerful tools, because you can dynamically combine partials with controllers.
I often use data-attributes to store configuration that I can't semantically markup so that the JS will behave in a certain way for those elements. Now this is fine for pages where the server renders them (dutifully filling out the data-attributes).
However, I've seen examples where the javascript writes data-attributes to save bits of data it may need later. For example, posting some data to the server. If it fails to send then storing the data in a data-attribute and providing a retry button. When the retry button is clicked it finds the appropriate data-attribute and tries again.
To me this feels dirty and expensive as I have to delve into the DOM to then dig this bit of data out, but it's also very easy for me to do.
I can see 2 alternative approaches:
One would be to either take advantage of the scoping of an anonymous Javascript function to keep a handle on the original bit of data, although this may not be possible and could perhaps lead to too much "magic".
Two, keep an object lying around that keeps a track of these things. Instead of asking the DOM for the contents of a certain data-attribute I just query my object.
I guess my assumptions are that the DOM should not be used to store arbitrary bits of state, and instead we should use simpler objects that have a single purpose. On top of that I assume that accessing the DOM is more expensive than a simpler, but specific object to keep track of things.
What do other people think with regards to, performance, clarity and ease of execution?
Your assumptions are very good! Although it's allowed and perfectly valid, it's not a good practice to store data in the DOM. Sure, it's fine if you only have one input field, but, but as the application grows, you end up with a jumbled mess of data everywhere...and as you mentioned, the DOM is SLOW.
The bigger the app, the more essential it is to separate your interests:
DOM Events -> trigger JS functions -> access Data (JS object, JS API, or AJAX API) -> process results (API call or DOM Change)
I'm a big fan of creating an API to access JS data, so you can also trigger new events upon add, delete, get, change.
I have a pretty big chat app I'm working on, and had a question about best practices for JS data storage...
I have a table populated with AJAXed data from the server, and the Javascript gets some info from that, and also from an internal object, also populated with AJAXed data. I was starting to store information about each chat in an object, like user status, name, etc., and realized... I have this table right here that I can use as data storage. It's persistent, it stays there at least as long as they're in the chat, so why not just add some hidden TDs or spans to it to hold this data, rather than dealing with a Javascript object? I don't know if there'd be a noticeable change in speed (dealing with an object vs having to parse ID tags and strings), but I was just wondering if there was any fundamental reason why using the table for data storage was A Bad Thing.
And, on the flip side, should I cease looking up data using the table altogether, and instead store all the data in an object (along with displaying it in the table)? Or is my current hybrid system (looking up in table for things that are in the table; using an object for things that aren't, rather than using hidden spans/tds) pretty good?
Populating the table, whether using innerHTML or DOM methods, is going to be worse performance-wise. Retrieving the data (particularly if via iteration) also becomes less verbose, easier to maintain and, again, better performance-wise. Using an HTML table is also a more fragile option, as if something goes wrong, other markup on the page could become invalid or, worse, it might end up displayed to the user.
There's also the simple fact it just seems hacky, workaroundy and dirty. It's an HTML table that is to present tabular data, it's not an SQL table for data storage.
JavaScript objects are pretty much made for what you're describing. Using an object makes even more sense and is a nice and clean option if the data you're getting from the server is already in a suitable form (i.e. JSON). Then it's ready for you and all you have to do is parse it.
I was just wondering if there was any fundamental reason why using the table for data storage was A Bad Thing.
I'd say it's fundamentally "bad" for the same reasons we strive not to mingle javascript or css in with the markup. The page HTML should be used for presentation purposes only. I don't think there's going to be a huge difference performance wise whether you use the table or a javascript object, but the javascript object would be much cleaner, IMO.
Set eg. each <tr> element to have a custom property eg .customData and place your javascript object there. Its a nice compromise - the data is seperated from the markup but directly related in the dom.
Storing the data in an object would make it easier to manage, but it would be good practice to also store a reference alongside of that to the element (makes crud easier).