Welcome to UI app architecture showcase

It is customary in frontend world to demonstrate different architecutres by implementing a simple counter and then a TODO list app. The problem is, both cases are quite simple and neither showcase nor test a given apporach against real world requirments. This project attempts to bridge the gap by implementing a minimal set of requirments such as tabbed ui, user input validation, derived fields, timed actions etc. that you are likely to have in the real world. The goal is to provide standrtised prooving ground, where same app implementations can be compared (much like TODO list apps projects) and people looking for hints at code organization can study them. My initial personal goal was to have a set of requirments to test new frameworks before using them in my proffesional projects.

Set of requirments provided can also be used for learning purposes. I made them highly representative of enterprise app development process.

Individual implementations are contained in branches. To make your own - start in the main branch, src folder contains app entry point and mock api clients to be used.

Successful implementations

branch | demo | SolidJS

branch | demo | Svelte

branch | demo | Rematch2 (Redux)

branch | demo | MobX MVVM, classes and observable decorators

Requirments

Disclaimer: this requirements are intentionally formulated in a realistic manner, rather than best possible manner. Use commonsense and look at API signatures. Unless someone specifically told you otherwise, this task is not about aesthetics or CSS. This task is about code quality and architecture. Final result does not have to look exactly like sketch, or be beautiful, but must have correct behavior. That being said, you should probably reuse HTML and CSS from an existing implementation to make your life easier and maintain unified visuals.

Lets build an application to negotiate car and insurance deals online (something likely to be used by a manager at a car dealership). Desired final result sketch:

1. Api is emulated by 3 client classes in ./src/api . Files in that folder are to be used as-is (no modifications to them).

2. App is to use tabs, 1 deal per tab. Many independent deals can be in-process at the same time. App must have buttons to create a new tab and close existing tab (see sketch).

3. When a new tab is open – list of possible car models must be retrieved from getAvailableCarModels and of possible insurance plans from getAvailableInsurancePlans. This lists are not shared between tabs – each tab has its own. Each list can be refreshed from the api via a button. User must select 1 car model and can select 0 or more insurance plans. Once car model is chosen – it is displayed in tab header.

4. Final price of the deal formula:

Final price = car base price + sum(insurance plan rate * car base price) for each insurance plan.

5. For downpayment, user can enter any string, but it is only valid when a positive whole number is entered. If anything else is entered – an error message is shown:

For invalid number:

For negative number:

If final price is available and downpayment exceeds it:

User is allowed to enter K for 000 and M for 000000

6. ‘Set minimum possible’ button calls getMinimumPossibleDownpayment method from api and sets provided value to ui.

7. When a car model is selected and valid downpayment is available – user can press ‘Request approval’ button to call getApproval. If failure meesage is returned – it must be shown:

If approval is granted – notifying message is shown. If approval has expiration date – a timer in seconds is shown in that message and in tab header (header timer keeps ticking even when tab is not active):

When timer runs out - "Approval expired message" is shown inside tab:

Approval may be granted without expiration, in which case - it is perpetual (perpetual approvals are granted if AssetProtection insurance is selected).

8. Approvals must be cached for a combination of car model, insurance plans and downpayment. If a user changes any parameter – approval is removed, but if the user reverts changes – existing approval is used again automatically. User can have approvals for several valid combinations within 1 deal. Given approval is used as long as current deal params match the ones for which it was given. Approvals are not shared between deals.

9. If user has valid approval – they can finalize deal via finalizeFinancing. If not successful – received error message must be shown. Otherwise:

10. Once you are done, and only then! check additional requirments in requirments-advanced branch, to check flexibility of you approach aganist incoming changes.

App basis

This project was bootstrapped with Create React App. If you are working on a case that does not use React at all - the setup is up to you. Consult whoever gave you the task for additional constraints / expectations in terms of frameworks / libraries / patterns.