CODEWITHSUNDEEP
webpolymerpolymer-1.0web-componentpolymerfire
user2850571
user2850571

Reputation: 43

Polymer app best practices

I have best practices questions to respect while developing Polymer Web App.

Let's say I have a Todo app. The main element my-main-task is responsible for switching between those elements: list all tasks, view a single task, create a new task, edit a task and delete a task.

My question is: the new element must save data using firebase-document or iron-ajax by itself or delegate it to the my-main-task?

Upvotes: 4

Views: 1290

Answers (1)

alesc
alesc

Reputation: 2780

In the recent Polymer Summit (London 2016), there was a lot of talk of being lazy (as in lazy loading). This means, that you only load/render what you need and (in the best case) nothing else.

This said, the short answer to your question is: the new element should save the data by itself, as it is the most appropriate place to do so.

As for the long answer, bear with me for a while.

On the Google Developer's Web Fundamentals page, there is actually an architectural pattern named The App Shell Model. This pattern actually describes your my-main-task element.

Some useful quotes:

The app "shell" is the minimal HTML, CSS and JavaScript required to power the user interface /.../

/.../ In general, your app should load the simplest shell possible but include enough meaningful page content with the initial download.

This being said, it is unwise to put the logic for saving a new item into the app shell element (in your case the my-main-task element).

To go even further, let's have a look at the Polymer's sample Shop app (Github repo, Online demo).

If you look at the "app shell" element shop-app (source code), you can see that it only implements the following:

  • basic page layout (sidebar, content)
  • routing
  • cart data
  • cart logic

In this particular case, the cart data and logic is put into the shell element, since it is used across all of the pages, but otherwise no other business logic is implemented there.

As for the long answer to your question, let's take a look at the Checkout page, namely the shop-checkout element (source code). You can see, that all form related data (i.e. posting to the server) is done within this element and nothing is delegated to the app shell element.

Another example is the shop-list element (source code). Again, you can see that this element retrieves the data by itself and only interacts with the app shell element to change the section.

To conclude, let's name another good practice that is also contained in the aforementioned Shop app, which is the way the data flows within the app. There was an interesting talk at the Polymer Summit (Youtube video) regarding this, and the essence is the following: use one-way data bindings as much as possible and try to avoid two-way data bindings unless really necessary. To achieve this, the downward data flow (parent to child) should be done as a one-way data binding, and the upward data flow (child to parent) should be done as an event. This is essential for element reusability since the coupling between the elements is much lower.

Upvotes: 4

Related Questions