2 added 2 characters in body
source | link

Apply Object-Oriented Design to your code, and for UI development:

  1. Separate presentionpresentation and model Use a MV-whatever library/framework, or write your own, to help separate view/controller logic from data model. All communication with the backend should be done inside the model, and the model state should always be in-sync with the backend.
  2. Decoupling If object A knows about object B, then A can call methods on B, but B should not know about A. Instead A can listen to events from B. It makes sure there is no circular dependency. If your app has lots of events between components, then create an EventBus, or leverage an event-driven framework like Twitter Flight.
  3. Partial vs full render If your view is a table or list of items, your may be tempted to create methods like "add", "remove" to insert/delete one item into/from the collection. Your code could easily bloat when you have to support sorting and pagination. So my advice is: simply re-render the whole view even when there is a partial change. What about performance? well if your collection is big, then your should do pagination anyway. Web developer: make sure your event handlers are delegated to the view's root element which does not change.
  4. View model When your view's state becomes too complicated to maintain, for example, a Table view has to keep track of the row data, column data, sort order, currently checked rows (if it supports multi-check), etc, you should probably create a ViewModel object for those states. Your View object should call setters on the ViewModel if something changes on the UI (eg: user checks a row); and it should respond to ViewModel's change event by updating the UI. Usually you should avoid updating the UI if the change event is triggers by UI.

Here is a small but non-trivial app to help illustrate some of my points. You can find the code and view/model interaction diagram here: https://github.com/vanfrankie/pushpopbox

Apply Object-Oriented Design to your code, and for UI development:

  1. Separate presention and model Use a MV-whatever library/framework, or write your own, to help separate view/controller logic from data model. All communication with the backend should be done inside the model, and the model state should always be in-sync with the backend.
  2. Decoupling If object A knows about object B, then A can call methods on B, but B should not know about A. Instead A can listen to events from B. It makes sure there is no circular dependency. If your app has lots of events between components, then create an EventBus, or leverage an event-driven framework like Twitter Flight.
  3. Partial vs full render If your view is a table or list of items, your may be tempted to create methods like "add", "remove" to insert/delete one item into/from the collection. Your code could easily bloat when you have to support sorting and pagination. So my advice is: simply re-render the whole view even when there is a partial change. What about performance? well if your collection is big, then your should do pagination anyway. Web developer: make sure your event handlers are delegated to the view's root element which does not change.
  4. View model When your view's state becomes too complicated to maintain, for example, a Table view has to keep track of the row data, column data, sort order, currently checked rows (if it supports multi-check), etc, you should probably create a ViewModel object for those states. Your View object should call setters on the ViewModel if something changes on the UI (eg: user checks a row); and it should respond to ViewModel's change event by updating the UI. Usually you should avoid updating the UI if the change event is triggers by UI.

Here is a small but non-trivial app to help illustrate some of my points. You can find the code and view/model interaction diagram here: https://github.com/vanfrankie/pushpopbox

Apply Object-Oriented Design to your code, and for UI development:

  1. Separate presentation and model Use a MV-whatever library/framework, or write your own, to help separate view/controller logic from data model. All communication with the backend should be done inside the model, and the model state should always be in-sync with the backend.
  2. Decoupling If object A knows about object B, then A can call methods on B, but B should not know about A. Instead A can listen to events from B. It makes sure there is no circular dependency. If your app has lots of events between components, then create an EventBus, or leverage an event-driven framework like Twitter Flight.
  3. Partial vs full render If your view is a table or list of items, your may be tempted to create methods like "add", "remove" to insert/delete one item into/from the collection. Your code could easily bloat when you have to support sorting and pagination. So my advice is: simply re-render the whole view even when there is a partial change. What about performance? well if your collection is big, then your should do pagination anyway. Web developer: make sure your event handlers are delegated to the view's root element which does not change.
  4. View model When your view's state becomes too complicated to maintain, for example, a Table view has to keep track of the row data, column data, sort order, currently checked rows (if it supports multi-check), etc, you should probably create a ViewModel object for those states. Your View object should call setters on the ViewModel if something changes on the UI (eg: user checks a row); and it should respond to ViewModel's change event by updating the UI. Usually you should avoid updating the UI if the change event is triggers by UI.

Here is a small but non-trivial app to help illustrate some of my points. You can find the code and view/model interaction diagram here: https://github.com/vanfrankie/pushpopbox

1
source | link

Apply Object-Oriented Design to your code, and for UI development:

  1. Separate presention and model Use a MV-whatever library/framework, or write your own, to help separate view/controller logic from data model. All communication with the backend should be done inside the model, and the model state should always be in-sync with the backend.
  2. Decoupling If object A knows about object B, then A can call methods on B, but B should not know about A. Instead A can listen to events from B. It makes sure there is no circular dependency. If your app has lots of events between components, then create an EventBus, or leverage an event-driven framework like Twitter Flight.
  3. Partial vs full render If your view is a table or list of items, your may be tempted to create methods like "add", "remove" to insert/delete one item into/from the collection. Your code could easily bloat when you have to support sorting and pagination. So my advice is: simply re-render the whole view even when there is a partial change. What about performance? well if your collection is big, then your should do pagination anyway. Web developer: make sure your event handlers are delegated to the view's root element which does not change.
  4. View model When your view's state becomes too complicated to maintain, for example, a Table view has to keep track of the row data, column data, sort order, currently checked rows (if it supports multi-check), etc, you should probably create a ViewModel object for those states. Your View object should call setters on the ViewModel if something changes on the UI (eg: user checks a row); and it should respond to ViewModel's change event by updating the UI. Usually you should avoid updating the UI if the change event is triggers by UI.

Here is a small but non-trivial app to help illustrate some of my points. You can find the code and view/model interaction diagram here: https://github.com/vanfrankie/pushpopbox