How could I interpolate a one-time binding manually?
Here is my use case.
I have a list of a lot of elements. The elements just sets of controls. I get the data for the elements from the BE. Then I would like to leverage the AngularJS interpolation and set the controls` values. But I would like to avoid the interpolation of all the elements every time I change only a single control.
So, I use a one-time binding to set the values, but then when I change them they are not updated.
The expected result in the example is that once something is typed in the control, the respective one-time binded value is updated. Also, the one-time binding should remain there, since in my real case there will be a lot of controls and I do not want to strain performance when only one control is interacted with. A simplified example of mine can be found here (in my real case I have not only inputs, but checkboxes as well, but I believe that the approach should be the same for them).
After a research I found out that a directive should be used in this case. But I was not able to find a simple to understand example. So, could someone post it here, please?
Different from a directive solutions are welcome here as well.
First to understand your problem: Why do you want to avoid the angular change detection here? The only reason that comes to my mind would be heavy performance problems.
In one case here, there were one or two thousand of inputs, all with a binding. The application was a little sluggish, but still usable. We accepted this, as we had to re-implement all the binding manually otherwise.
If your binding is rather simple (no validations, conversions, etc.) and the values are not shown on other places while being edited, maybe it would be a way for you to use an AngularJS directive on a native HTML Input element that just listens to its onChange event to save changed data and gets updated programmatically whenever you know it changed from outside (if it does at all).
(Not talking about better using Angular, which has a much tighter grip on change detection ;-) ).
Related
two-way binding feature in angular is so popular, and according to angular community it is good when compared with one-way binding.
And there are lots of simple examples to explain how it works.
But my question is where does we use that feature in real applications.
- One example is using with input boxes, other than that is there any good uses of it?
Two way binding as a default wasn't wise because it creates perf issues (~2000 watchers and your app can go bad fast). It led to the introduction of {{::}} binding syntax (bind once syntax) in Angular 1. Overall I can't see where I agree that default two way binding is said to be a good thing by any knowledgeable Angular dev.
I can tell you for a fact, having written an application that displayed many lists of different kinds of objects simultaneously, that default two way binding was a mistake. It created far too many persistent watchers. The community overall seems to strongly agree.
So what you suggest here is correct; there are uses for two way binding. But those needs should be seen as few and far between. And even then, you could probably get around the need for it at all with a little thinking.
For me, two way binding is primarily useful for input fields. But the mechanism is most definitely downplayed now, it should be used sparingly.
Well, when you bind a label with a $scope variable, though the binding is two-way (by definition) it is only relevant in the direction JS -> HTML.
A two-way binding is only fully exploited in cases where the value can also be changed by the user, meaning any type of INPUT component (textbox, dropdown, checkbox, etc.).
One trivial (though one-directional) example is when you have a page that can be displayed in many languages. You would deploy $scope variable all over, and assign to them strings in the current language.
When the user switches language, the simple assignment of the new strings to the corresponding variable will yield the screen to be automatically update to the new language.
I've seen many data binding frameworks, such as WPF, AngularJS(Javascript), JSTL(JSP).
They are trying to separate UI and Data completely.
However, one main problem is that it adds complexity. Sometime, you have to write a lot of extra code (for example to extend a view class) just for one line of UI code.
In modern applications, there are many transition animations when changing one UI element from one state to another state. When use data binding framework, it seems not easy.
Are there any other cons of using a data binding framework?
For example, to set focus on a text input, so complex in AngularJS, See:
How to set focus on input field?
All of the following refers to the WPF.
You have to write a lot of extra code (for example to extend a view class) just for one line of UI code.
With regard to the WPF, this is rare situation, you can give an example?
There are many transition animations when changing one UI element from one state to another state.
In WPF since version .NET 3.5 appeared VisualStateManager:
The VisualStateManager enables you to specify states for a control, the appearance of a control when it is in a certain state, and when a control changes states.
His goal - is to define the application state, and each state to do an action, such as an animation. In this situation Binding is not used as such.
When use data binding framework, it seems not easy.
I do not think it's disadvantage. Data Binding needed as you mentioned: separate UI and Data completely. In fact, the whole MVVM pattern is based on a powerful technology as Data Binding. This feature allows you to create an abstract connection between Model and View via ViewModel. And the key word is Data, everywhere where there is work with the data, it is better to use Data Binding.
Binding allows you to do many interesting things, such as Validation, Converters and much more. It is typically used for Binding properties, and nothing more. To work with the UI using other features like VisualStateManager, Triggers, DataTriggers, etc. and it is not difficult when you use it to its destination, just need to get used to.
The only downside - is that Binding can be used for other purposes, such as use of the Converter when you can not do without it. And yes, at first it may seem unusual, but I do not think that this a drawback, the same can be said about other technologies.
Even as a drawback can be said about the performance. If you assign a value directly or via Binding, assigning a value directly will be faster. But I think that the advantages of Bindings allow not pay much attention to it.
I have a ng-repeat that generates around 300 rows. I can't implement infinite scrolling since i need all the rows present on the page. For each row there are 3 elements.
When the page loads, i get all the rows from the database and if the element exists i display it, if not i have the option to add it by clicking on the place where the element would otherwise be. When clicked a form is displayed right under that element.
The form has 4 inputs, which is quite a lot of html. Now since we have two-way data binding, and we are inside the ng-repeat isolated scope, i can't use one form for all 3 elements (since the values in the inputs would be shared), i would need one for each. Considering the amount of rows, rendering so many forms takes more than i'd like.
To get a better idea of what i'm working with (visually, the code is not relevant anymore) http://plnkr.co/edit/xNYUbi?p=preview
I want to stick to the form dropdown under the add element option, so making a modal isn't an option.
How should i approach this problem?
I'm not certain I understand the specific use case here so I will give some generic advice that I hope helps. When working with lots of data angular, there are a number of options:
ng-grid: Has an edit mode and paging so with the correct settings you can pull down all your data, set the data source for the grid and the performance should still be pretty good.
ng-repeat: If you have to have a custom U/I or you need additional functions in your U/I, ng-repeat is about as good as it gets. As long as you don't have nested repeats (can be bad) and you craft your UI carefully you should mostly be all right.
Assuming that ng-repeat is still too slow you could think about implementing some form of paging or ng-infinite-scroll. With either option you can still load the entire data set initially and then display it in chunks rather than all at once.
At the end of the day - if the performance is unacceptable when you try to add all the elements to the DOM the only real solution is to alter the way those elements are added or simply don't add them at all (which is where all the above solutions really lead you). This might require talking to your client or going through a bit of re-design, but in the end it should be worth it. Best of luck!
I see a 'Tag' property in the design view for most WinForms controls. I have never used this tag and want to know why I would want to use it.
It allows you to store some of your own data with a control. It mostly useful in tree controls where you might want each node/leaf to have some extra data associated with it. This way when you click on a node you can perform an action relevant to the node.
Its a general "catch-all" for additional data you wish to store with a control.
I too have never used it.
We perform heavy use of tags. We have some methods for checking input, and these methods checks whats in the tags in order to know what control to perform.
IE: if a textbox has RQ=1;DT=int;MAX=100
the automatic method knows that this text can not be left blank, that should accept only integers within 0 and 100.
We have a complete pseudo declarative language for this.
Kind of useful!
More specific for your question, Tags are for your use.
for example you have a lot of buttons with single method handling clicks. then at handler you have do differentiate them from each other. So you put some sort of id (or reference) and then access it there.
Or do you populate your form controls manually by a method?
Is either considered a best practice?
Generally, if data binding business or DAL objects is possible, I would use it. The old axiom holds true: The most error-free and reliable line of code is often the one you didn't have to write. (Bear in mind, however, that you need to know exactly how that data binding occurs, what its overhead is, and you have to be able to trust the framework and your source objects to be error-free!)
You would, as others have mentioned, manually populate if you needed specific functionality not brought to bear directly by binding, or if there is an issue with data binding business/DAL objects (as occasionally happens with certain 3rd-party controls).
Well, it depends. I have tended to use databinding wherever I could - it is darn convenient, but on occasion, I'll populate them manually. Particularly, I find it useful with controls like the DataGridView to use databinding. It makes filtering quite simple.
It really depends from what you are trying to achieve.
Databinding is simple and powerful, but if you need more control or some kind of side effect, you can manually populate control from a method.
Personally, I start with a databinding first, than change it later if it is necessary.