I recently learn NgRx (actually still trying to learn) and updating our existing projects to Angular 5 and ngrx structure. So far so good but one of our pages got a data table with more than 1k+ form fields in it.
I normally was using reactive forms to populating form fields from state slice and updating changes to state when user send the form but with that much of form fields creating form controls probably will be very costly and don't want to slow down that page and seems like it is not ok to just use basic text boxes and ngModel with NgRx structure
How can I solve that problem in NgRx way. Thank you in advance
When you use template driven form (By using ngModel directives on input elements), angular automatically creates FormControls on your behalf and attaches them to all registered input HTML elements, and then register these FormControls with the NgForm directly that angular creates and attaches to the form element for you. On the other hand, if you choose to use reactive form, you, yourself, have to explicitly create the top level FormGroup and any FormControls or FormArrays, and register these FormControls and FormArrays with the parent FormGroup and manually bind these to your form element and any input elements you want angular to keep an eye on. So logically, there should not be any notable difference in terms of performance. You also should not make any assumption about the performance problem that might by caused by using reactive form, measuring is your best answer in this case. But using reactive allows greater control and flexibility over your form
ngrx store is just a state manager, it is very similar to redux store, in fact, ngrx store is inspired by redux store, in one word, ngrx store allows you to put all your app states into a central location, so it is easier to manage and retrieve, so you don't really have to use it if you don't need to, there is not really a "ngrx way" of doing things
Related
Trying to craft a way for our designers to create custom asp.net webforms for our customers. The basic idea is that we have a general set of fields that can be saved, with each customer using a subset of those fields, each customer may have it's own names for similar concepts (ie one customer may use 'patient' and another 'customer'). Staying in customer context will help the designers build the correct form to meet the customers needs.
Now to do this I need to get as much as I can into the design experience as possible. I have a set of custom controls that derive from base controls like asp:TextBox and implements an interface to allows me to iterate over the controls and insert values from a data store, or fetch values to persist (Done). All of these controls need to be bound to a data point in my record object. I have a metadata system set up to allow the binding, but where I am running into trouble is in getting the list of available fields into a UITypeEditor. Namely, I haven't figured out how to (at design time) set the customer context on the form, and then access and use that value on each controls custom property editor (also at design time). Is this possible? Am I looking at this problem the wrong way? A form always has 1 and only one customer context. So in my forms project, each form will have a different customer id set to it.
As a second question how can I debug these editors? There is an expectation of web context in the editors, but there is no asp.net property grid. and even if there was, the editors are winforms components that wouldn't run in a browser.
I can include the code I currently have if it simplifies the problem, but even a simplified example is a half dozen classes.
I resolved these issues, posting here in case a general solution can be useful to anyone in the future.
I was able to get around this problem a bit by going the other way. My parent Page iterates over it's controls, and sets the CustomerId on all the controls that implement a specific interface.
As for debugging. Some refactoring got me to a place where I can easily swap out the webforms specific parts of my implementation for testing.
I am looking for some design "best practice" or heuristic to address performance issues on a webpage.
Basically, there are dropdown menus with up to 10,000 choices and each is in an tag. So I have many thousands of extra nodes in the DOM model. I think this is slowing down the javascripts that parse the document after it loads, but also it is slowing down the initial page load to get out all that data.
I would like to lift those drop downs off the page entirely, so instead of combobox style controls, it will have a link to a modal popup which will contain the picklist. I think preloading and caching these popups on the client will prevent the slowness of loading the initial page, and get all those 10,000s of off the DOM so that the existing script performance will improve.
With my limited experience in web development, I am not sure if the best thing is to create some sort of page/control/service/etc for the initial approach. Once I am confident I am using the correct approach, I should be able to work out the details.
Will the dropdown selections be changing frequently or static? If they're static, you could maintain the list as an enum in your VB code behind and have the dropdown use the enum as its data source.
If they're dynamic, I'd explore breaking the list up if at all possible into smaller chunks that could let the user "drill down" from general to more specific items. For example if this dropdown lists types of animals, you might have an initial dropdown subset:
Mammals
Reptiles
Amphibians
Upon selecting one of the above, say Mammals, then you'd hit the database for a more specific subset:
Apes
Marsupials
Finally the most specific subset, if they choose Apes:
Baboon
Chimpanzee
Human
Orangutan
If the list cannot be broken down in this way, then I'd try to implement a Google Instant style autocomplete functionality. If you read up on jQuery, there is an autocomplete control which serves this purpose; you should be able to tie that to the database to be able to query as the user types and thereby pare down the results.
I'm working on a webform with various controls. Depending on user-input I show/hide (using JQuery's show()/hide() functions) bits of the GUI. However if the form is posted-back and fails validation, I want the GUI to remain in the same state it was pre-postback rather than returning to the first-load state. Obviously the ASP.Net controls retain state, but I have HTML containers that are pure client-side objects.
In attempting to design a solution I find myself heading towards the murky (and tricky-to-debug) realms of hidden form fields - more reminiscent of my pre-JQuery work than anything 21st Century :-(
Can anyone suggest a better way ...?
If anyone's reading this:
I went with a JQueryish solution - a JS function now runs onready. It checks the state of any ASP.Net controls which act as 'visibility controllers' (which obv. maintain their own state across postbacks) and sets the UI accordingly via JQuery calls.
I think the trick is to use the hidden fields to persist the state of the client-side fields.
So the process is something like:
user action -> update hidden value(s) -> update UI
Then when the page posts back, you re-set the UI:
page load -> update UI
Is it my understanding that Helper methods are really the place where you can do the hard core logic that we would have done in lets say custom controls in ASP.NET? For instance I work for a .com which uses classic ASP.NET. The nature of our site is VERY complex, so we reuse and render different forms for thousands of products. Every product could have a different configuration form. We have a very complext RenderForm.cs custom server control that performs all the logic. Based on some configuration settings from a table in the DB, it says ok, for Product 1123 it reads the setup (that our users confugure form our internal admin system) and takes that and spits out the dynamic form (using literal controls and what not) to the p age.
So I'm thinking MVC now. Yea yea, it's all done in the View. Well partially. You're still going to have a need to have some custom logic in some .cs where it's not all embeded in your view. That would be foolish to think you're not going to have some class that will spit out some HTML..like some very hard core extensive helper methods.
So my question is, are helper methods or class where you now do your custom server control type of logic? it's basically kind of the same concept in that you need a place to put your "hard core" HTML rendering logic in some class other than a controller. Your controller is not responsible for rendering. So helper methods I guess are the so-called custom server controls in a way that I have in classic ASP.NET, figuratively speaking. I just need a yes or now on is the consensus that helper methods is the place to do all my hard core reusable logic that spits out html to the page and where I can embed custom controls into my view? Looks like it.
"Helpers are essentially static classes, designed to contain the UI logic that otherwise clutters up your UI. Think of these as UI utilities." link text
Yes, that is right on. If you do it right, you will start with the HTML helpers that MVC gives you, and you will gradually build up your own set of helpers that do even more and more for your specific project. You can get to the point where your view has only a few lines of code, which say something like, "Render entire view for Product 1123". The helpers will become your own "language" of renderers specific to your project, and you will be applying configuration, validation and everything else in a very DRY (Don-t Repeat Yourself) manner. It's phenomenal.
Update: Of course, only presentation stuff should go in your helpers. The goal is to stay DRY in your views. You still need to be careful to put into your ViewModels the things that belong in the ViewModels.
I would say "no"... or rather "only where you have to". More often than not, you can instead do the logic in the Controller (or a Service) and end up passing all the data required back to the View in ViewData. Somtimes this will mean multiple Views from one ControllerAction, less often it will mean logic in your View, and occasionally it means HtmlHelpers.
When you decide to use Helpers, it should be with the consideration that this means generated markup that won't be... well, in your markup. If you have (or later hire) a designer, that can be a problem. Or if you need to make a minor change to your layout, where do you go first? Your View or your Helpers?
[Edit] Also should ask yourself this: where is my code more easily unit tested? In a Service class which is just handing back View Data, or in a class that builds entire chunks of HTML and returns them as a String? If you're using TagBuilder, as you probably should be, then any change in the implementation of TagBuilder (even a change of whitespace handling) will break tests on a Helper without your code changing.
I'm not saying "don't use Helpers", I'm saying "don't abuse Helpers".
I would like to create a general form so that it can deal with creation/read/update of an entity. When creating an entity, it may only contain a subset of all fields; when updating the entity, it may contain a different subset of fields; and when reading the entity, none of the fields are editable. Anyone with experience in designing such a form in Flex? Thanks in advance.
I was frustrated with the quality of the flex forms as well, especially managing the validation, so I wrote my own form control. It's a bit haphazard and buggy at times so it's not ready for sharing, but I'll cover the ideas:
Separated into a layout part and a data part, matched by keys. Both are basically combinations of AS3 Objects/Arrays containing the properties I need.
Describe all the possible visible elements in the layout, the validators needed, visual properties, labels ,etc... Every element in the layout is an Object in an Array. The primary array is ordered and displayed via a VBox. Any nested arrays are displayed in a nested HBox (e.g., useful for radio options).
The data part of the form is where you can set initial values, "editable" properties, "model" properties (for combo boxes), things like that. The data structure is an Object hash where the keys map to elements in the layout. If an entry from the layout does not exist in the data definition, it does not appear. This allows you to easily hide sections you don't want to show.
Has an errors sections where validation or server errors can be displayed.
Has a collect function that collects all the data into an object hash.
Has a validate function to control when the validators are triggered.
Non editable fields show up as labels.
Basically I've implemented my own "Form" control, and each entry in the layout (when displayed) becomes a custom "FormItem" control that will be whatever type the layout described. ("text","combo","heading",...)
Hard to describe without visual examples and some code, but that's the basic idea. You're on the right track thinking that you need your own control. There's too much hand-holding required for the generic forms, and lots of redundant code.
Check out Rocket Framework .. you gonna love it..
Want to automate winforms? not just CRUD, this help creating any type of winforms controls. The Rocket Framework for WinForm (using .net c# 4 ) provides a set of easily utilizable generic library to seemlessly develop 'form based' application/ control / custom controls for .Net.