If I have a page with three cascading dropdownlists, is that an example of controlling the state of a web application (assume it is part of a larger application)?

I want to make sure I understand state management and the need for a system like Vuex and Redux and having the store pattern, one singleton to run it all through, reducing complexity, and so on I know the React and Redux folks said it'd be like wearing glasses, you know if you need them, and in addition, this could be done quite easily with no framework.

But, in general, is the usage of a cascading dropdownlist an example, albeit incredibly simple, of keeping track of "state"?

For reference of a dropdownlist see, https://stackoverflow.com/questions/18351921/how-to-populate-a-cascading-dropdown-with-jquery

jQuery(function($) {
    var locations = {
        'Germany': ['Duesseldorf', 'Leinfelden-Echterdingen', 'Eschborn'],
        'Spain': ['Barcelona'],
        'Hungary': ['Pecs'],
        'USA': ['Downers Grove'],
        'Mexico': ['Puebla'],
        'South Africa': ['Midrand'],
        'China': ['Beijing'],
        'Russia': ['St. Petersburg'],

    var $locations = $('#location');
    $('#country').change(function () {
        var country = $(this).val(), lcns = locations[country] || [];

        var html = $.map(lcns, function(lcn){
            return '<option value="' + lcn + '">' + lcn + '</option>'

I don't think I was clear. I am only asking if the dropdownlist scenario is an example of State on the frontend. I did not mean was it the best way or a good candidate, only if it is an example, albeit incredibly simple. Another way, if I had a button that change colors based on some other choice on the page. Is that "State"? I'm only trying to understand what constitutes "State." It is not really a question about Vuex, Redux, or the like.


3 Answers 3


The first question is

What is application state?

In case of a modern front end application this comes with a special twist

Is every state my application is in application state?

Since you mentioned redux and vuex the latter is the interesting question.

Regarding you example of a dropdown list the answer is: The state the dropdown is in is clearly a state your application is in. The follow up question is:

Who is interested in that state?

Sometimes you have state which is only of partial interest for the system as a hole. Then you would model that kind of state within the context of this very component. This is no application state.

But when more than one component is involved identifying or modifying this state it becomes application(wide) state. This was the reason the "store"-concept was popularized.

Instead of dealing with implicit / indirect ways of components talking with others through a chain of connections (a number of hops away) a more centralized, explicit way was chosen. This makes communication paths visible.

As a rule of thumb I came up with for any non trivial project default to using the store. Component state is most of the time the exception.

Regarding your example: This is a good example in as far as you could raise questions like "who needs to be informed when information changes?" and "is there a need of changing the current selection automatically depending on another dropbox?". And the more components are involved the more likely you should use a store.

  • Is the store then of value more so when there are lots of users, maybe all changing things in the backend db, updates, deletes, etc.? And I have a lot of connections on the front end to those pieces via a widget or something else?
    – johnny
    Commented Dec 27, 2019 at 22:09
  • @johnny no. This is independent from the users. It is only to help you do the heavy lifting to deal with complexity. You have a certain number of components each interacting with one another. Introducing the "store pattern" is introducing complexity on the one end. It doesn't come without a price. But when the complexity of passing relevant data around and keeping an eye on who changed what passes a certain line, the complexity by introducing the store pays off: it helps to lower the overall complexity. It is all about (inter)communicaton patterns between components. Commented Dec 28, 2019 at 14:32

Values are being cached on the client. If this is all that is being done, you are essentially replicating what the browser already does: caching stuff from the internet.

To start, just rely on good ol' fashioned AJAX calls using a GET request to get the data for the dropdowns each time. Have the server send the proper cache control headers. The browser does the caching for you.

Sorting and filtering the options can all be handled server side, simplifying the JavaScript. Be sure to authenticate your AJAX requests.

If you need to send sensitive information in order to filter the options, like tax information or other kinds of personally identifiable information, then switch to a POST request. In this case some server side caching can alleviate many performance problems.

Auto fill drop downs alone don't justify switching to a heavy front end framework. You'll need other uses for those big JavaScript frameworks before it's worth the time writing additional JavaScript to do something the browser already does.

  • From what I understand, this is not a question of using a "heavy front end framework" (which in case of vue is not correct) at all, but of "how much complexity should I jump into when using such a framework". Commented Dec 25, 2019 at 8:58

State management means keeping the last state of user selection through trips to the server before page form final submit. In your case if one of your dropdown-list depend on selection of previous dropdown-list (common) to get populated then any trip to the server will set the first dropdown-list to its original state and that is what you wouldn't want to happen so you either solve that with using Ajax(recommended) or save the selection of the first dropdown in session for example.

Back to your question about using Vuex and Redux: it depends on the framework you are using in ASP.net state is managed by the application. For me personally I wouldn't use JavaScript library (Vuex or Redux) for state management(JavaScript could be disabled by your users) I would follow Microsoft recommendation and put the effort of designing my state management.

Some of the things to think about to make your choice on what to use(in ASP.net) are:

  • How much information do you need to store?
  • Does the client accept persistent or in-memory cookies?
  • Do you want to store the information on the client or on the server?
  • Is the information sensitive?
  • What performance and bandwidth criteria do you have for your application?
  • What are the capabilities of the browsers and devices that you are targeting?
  • Do you need to store information per user?
  • How long do you need to store the information?
  • Do you have a Web farm (multiple servers), a Web garden (multiple processes on one machine), or a single process that serves the application?

then for client side you can use one of the following:

  • View state
  • Control state
  • Hidden fields
  • Cookies
  • Query strings

and for the server side you can use one of the following:

  • Application state
  • Session state
  • Profile properties
  • Database support

To read more about the subject of state management in ASP.net here is the link: https://msdn.microsoft.com/en-us/library/z1hkazw7.aspx

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.