These are criticisms of the original test.js provided.
- The whole body of this script should be wrapped in an IIFE to isolate it from the global scope.
- Orders should probably be defined as a class that you can create instances of, instead of just defining them as loose object literals. If you're looking for a more OOP approach.
- You could even go as far as you abstract away the acquisition of the orders list into some kind of service factory, which for the moment could deliver the test data. This would make it easier to switch to acquiring the orders from an API at a later date.
- I'm not sure if this falls outside the scope of this test, but I personally would use some kind of MV* framework such as AngularJS or React to do this exercise. (However, I assume the purpose of this test is to test my knowledge of vanilla ES5 JavaScript and the DOM.)
- I would also write the application in modules, which I could then bundle using build tools such as Webpack or Browserify.
- The view and model logic is all tightly coupled together.
- The
modalfor specifying the attributes the order is being created and appended to the DOM every time you click the "Create order" button. Why not just create the form once and toggle the visibility when it is required. (Minimizing DOM reflows and repaints.) - When you update the
color,size, orquantityattributes the order's view updates. However, when you modifycustomername the view does not update event when you click the "Add order" button.
This is an explanation for the changes I made during the course of the test, the result of which can be found in app.js. I also renamed test.html to index.html to make hosting on GitHub Pages easier.
I split out the application into a few modules.
- Model
- A model class, essentially an implementation of the Observer pattern, a way of wrapping data with accessors that have callbacks to notify an attached view.
- OrderView
- An order view class, that when instantiated creates an element by cloning it's base template element
OrderViewTemplate. It then binds itself to the model through theonUpdatecallback. When it's model changes it triggers the bound_onUpdatedmethod, which in turn updates the view.
- An order view class, that when instantiated creates an element by cloning it's base template element
- ServiceLocator
- A basic implementation of the Service Locator pattern, used to decouple the
OrdersandOrderForm. Useful if these elements need to be switched out in future.
- A basic implementation of the Service Locator pattern, used to decouple the
- OrderForm
- Provides an instance of
OrderFormwhich binds the value of form inputs intest.htmlto a new ordermodelprovided in thecreateOrdermethod. If the creation of the order is cancelled the model is deleted and the view updates accordingly.
- Provides an instance of
- Orders
- Provides order data from static data, but in the future could be swapped easily for an external resource acquired through AJAX.
- App
- Initializes the application, get dependencies from ServiceLocator, and instantiates objects required. Then orchestrates the form, models, and views.