Remember angular toggle state after page refresh without js cookies - javascript

I've got two sections that are being shown and hidden using angular. After filling few fields, I need to validate the data server-side, and refresh the page - then, div's with ng-show / ng-hide directives are losing their memory. I saw a solution for that problem using js cookies, but I think it's not a good practice for my problem. Is there something to remember that another way, or should I do this with cookies?

Related

Speed up rendering of page with many custom directives in AngularJS

I'm currently rebuilding an enterprise app in AngularJS. It has a multi-page form with thousands of fields, which are all wrapped in custom directives (for validation, formatting, and standardization purposes) based on the field type.
I've tried to optimize these directives as best as possible (one time binding, ng-if where possible, lazy-ng-if, no $watch functions, and minimal $rootScope.broadcast's), but I'm still faced with a several second delay when loading each form page (about 50-or-so fields each) with ui-router. Looking at all my performance measurements, it seems like the delay is coming from angular compiling and rendering all these directives.
So my question is, how do I make these directives render faster? Is there a way I can compile/render the top section of my form and make it usable before the rest loads? Right now with ui-router, it seems like nothing appears until everything on the form is rendered/compiled.

Can Sisyphus deal with a page which is displayed by ID?

Sisyphus is a plugin that deals with auto saving of forms in local storage.
It works pretty well on first look. What I want to know, is it possible to use with a dynamic page driven by an ID.
eg: MyPage/1 and MyPage/2 (MVC url's but could equally be querystrings), such that the page is rendered, maybe bringing some value back from a database, rendering some unique controls.
In other words, can Sisyphus deal with a parameterised page?
Turns out it's actually really easy.
We can use the locationBased option as per documentation
$("form").sisyphus({
locationBased: true
});

Best approach for On demand loading of tabs and form submission

I am developing an app using angularJS. This application has about 5 tabs and this is mainly a form and a single submit option for all tabs.(similar to employee data maintenance) The form is loaded with data of the user when the page gets loaded and user can edit and resubmit the form.
Since loading all the 5 tabs in the initial page load will effect the load time of the page , so i am planning to use on demand loading of contents and API.
1st approach:
One thing i can do is loading only 1st tab on initial load and load the other tabs based on click on the tab and using ng-include to include partial views. So in the end user can submit the form and client side validation can be done easily.In this case page will have DOM elements of all activated tabs.
2nd approach: By using routing (i am not much familiar with this). But from my understanding this logic will replace the DOM of a tab when user switches tab unlike 1st approach. So there is a need of using service or some other technique to save the data. But i want to retain the DOM of previous active tab even when tab is switched. So can it be done?
Finally, What is the best approach among above two OR is there any other good techniques to achieve same?
I think Option 2 would work best for you. AngularUI router (https://github.com/angular-ui/ui-router) would help with this above the standard ng-router.
Rather than save the DOM between tab switches, you could just save the data and re-bind when you switch tabs.

Changing html form index when a new form element is added

I am working on an old legacy application which used document.forms[index] approach to access elements in the form and to submit the form. My task is to add a new top panel with few textboxes and buttons. I am using a form for this. This top panel is to be included in all the pages in the application. Now, all the pages stop working since form[index] needs to be updated in all the pages. I know using the form name is the best approach. I have around 1000 places to change. What is the best approach to avoid this problem? I still want to use form for my top panel since I am using spring forms to get the data. Any valuable advice will be appreciated. Thanks.
If you looked up the definition of "unmaintainable", that would be a good example.
One trick might be to leave one set of forms, hidden, with the legacy stuff in them, then make another set, lower in the HTML, that the user sees. Then use some JavaScript to map the data back into the original forms in order to continue to work with the expectations of the legacy code. This keeps everything in the same index-order.

Client-side JavaScript ViewState Update in asp .net forms

I have stumbled upon the issue when I need to retract html controls I've added client-side using JavaScript after the postback (due to server-side validation - this is not optional).
Please tell me if the way I'm trying to achieve this is cr*p and there's a better way of doing this.
basically, what I'm doing is cloning a textbox control for up to 10 times on the page when the user hits "Add" and storing entered values from each of those texboxes in a hidden field to read from in the code behind. This works fine, however, when the server side validation doesn't pass after postback, all those dynamically added (cloned) texboxes disappear, since ViewState knows nothing about them.
I am considering 2 possible solution, both of which seem hacky:
Rebuild all cloned textboxes on document onload() using stored values in the hidden field
wrap the form in ajax update panel and place the cloned texboxes outside of it, thus, not refreshing this part of the screen on postback
now, is it possible to somehow "update" ViewState to make it aware of all the html controls I've added using client-side script? Any better ideas? I'd like to achieve this with client-side script, therefore not considering cloning textboxes on server-side, sorry.
You cannot modify the ViewState on the client side. If you do, you will invalidate the viewstate and receive an error on the postback.
In your case you might want to consider using javascript and jQuery to render the text boxes on the document ready event with the values stored in your hidden field. I'd recommend taking a look at jQuery templating, particularly if you can store your data as JSON in the hidden field (http://weblogs.asp.net/scottgu/archive/2010/10/04/jquery-templates-data-link-and-globalization-accepted-as-official-jquery-plugins.aspx).

Categories