How quickly could populate * dependent on each other * <select> drop-down lists in rails?

Question

Users need to choose a car.
We have several drop-down lists when choosing a car, to select the year, make, model and submodel. Initially, we do not know what to use make / model / subodel to select options, since they are interdependent.
Once we select a year, we use ajax for queries that request ActiveRecord to populate the drop-down list.
Then, when we select make, we use ajax to query and populate the model drop-down list. Then, when we select the model, we ajax request and fill out the drop-down list of submodels.

The problem is that it is a lot of separate network requests, but in real conditions of low bandwidth, network problems, etc. quite often pauses occur that strongly affect the user interface and sometimes lead to crashes.

What approaches will help to avoid all these network requests. Would it be possible to save all several thousand combinations of model models in a client browser?

Currently, data is stored in an SQL database accessible through ActiveRecord in the Rails environment. Each drop-down list leads to a different query, because you cannot show the filling and showing make until you know the year, and you cannot fill and show the model until you know what to do. The same goes for submodels (although I skipped the submodel from the rest of this post for simplicity!).

Will the session ( http://simonsmith.io/speeding-things-up-with-sessionstorage/ ) store JSON data for 10,000 combinations? I see that sessionStorage can usually be relied upon to have at least 5 MB (5,200,000 bytes), so that gives me 5,200,000 / 10,000 = 520 bytes per record. Probably enough? If this is saved for the session and between pages, then in many cases we could actually drop it on the previous page, and if he had time to complete, we would not need an external call at all on the corresponding (next) page. We will need to update this data either from time to time or on demand, since new year-models of models are added periodically (several times a year).

Ultimately, I think that the solution here can be very useful for a large number of applications and companies. An example here is the choice of the car itself, which it uses by dozens of major car insurance sites (which now make multiple calls). A general assessment of client-side storage for relatioship dependent sdropdown can also be displayed in many other situations, such as making-brand-year online purchases. The backend framework for populating sessionStorage can also be implemented using various backend frameworks.

Other options might be google Lovefield attempts - https://github.com/google/lovefield Read more at https://www.youtube.com/watch?v=S1AUIq8GA1k It works with open source and works in ff, chrome, IE , Safari, etc.

It seems that sessionStorage might be better for our (significant) business than basing it on the google 100-day version of dev, although it's open source.

Answer 1

Hello, you can create a JSON object for all the details and based on the selected value you can encode the array and fill in the value. let me

var cardetail = [{ "name": "MARUTI", "model": [{ "name": "SWIFT", "year": ["2005", "2006", "2008"] }, { "name": "ALTO", "year": ["2009", "2010", "2011"] }] }, { "name": "Hundai", "model": [{ "name": "I20", "year": ["2011", "2012", "2013"] }, { "name": "I20", "year": ["2013", "2014", "2015"] }] }]; var currentCumpany = null; var currentModel = null; $(document).ready(function() { $("#company").append("<option value=''>Select Company</option>"); for (i = 0; i < cardetail.length; i++) { $("#company").append("<option value='" + cardetail[i].name + "'>" + cardetail[i].name + "</option>"); }; $("#company").change(function() { for (i = 0; i < cardetail.length; i++) { if (cardetail[i].name == $("#company").val()) { currentCumpany = cardetail[i]; } }; $("#model").html(""); for (i = 0; i < currentCumpany.model.length; i++) { $("#model").append("<option value='" + currentCumpany.model[i].name + "'>" + currentCumpany.model[i].name + "</option>"); }; }); $("#company").change(function() { for (i = 0; i < cardetail.length; i++) { if (cardetail[i].name == $("#company").val()) { currentCumpany = cardetail[i]; } }; $("#model").html(""); for (i = 0; i < currentCumpany.model.length; i++) { $("#model").append("<option value='" + currentCumpany.model[i].name + "'>" + currentCumpany.model[i].name + "</option>"); }; }); $("#model").change(function() { for (i = 0; i < currentCumpany.model.length; i++) { if (currentCumpany.model[i].name == $("#model").val()) { currentModel = currentCumpany.model[i]; } }; $("#year").html(""); for (i = 0; i < currentModel.year.length; i++) { $("#year").append("<option value='" + currentModel.year[i] + "'>" + currentModel.year[i] + "</option>"); }; }); }); 

 <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script> <select id="company"></select> <select id="model"></select> <select id="year"></select> 

Answer 2

First, if the required bandwidth is too expensive, you can probably check the cache and then start making queries for the popular make / models / subodels as soon as (or even earlier) the user selects the year and caches it. There's even a full RDBMS for the browser now (full disclosure: its new and I haven't played much with it), which sits on top of indexDB.

In terms of choosing which ones to preload, you can do this on the basis of units produced, units sold, ratings of car and driver logs, data processing your requests from real users, no matter what.

I believe that from a UX point of view, you should at least cache the requests that the user really does and offer an option to download to go back to the last year / model / model they were looking for, instead of typing all fresh at every visit. The presence of pre-loaded cars facilitates the work. How much you want to put pressure on the envelope with a predictive analysis of what a given user can find depends on your team skills / budget / time constraints.

I understand that this is not a complete answer as such, I'm not sure how I stated that it has one question (for example, “use this strategy / structure / library and all your problems will magically disappear!” Even makes jennyenned fries! '). But, faced with such a problem, my first thought is how to get more (I hope, relevant) data to the client faster, which, I hope, move to a faster (in the sense of UX fast).

I would also recommend that your popular data in json files be requested and not deleted every time on the Rails / ActiveRecord / Database server. Only this will save precious milliseconds from your response time (not to mention the use of load on these machines).

It doesn't look like the data is really changing, 2009 Toyota Rav 4 has the same specifications as in 2009.