Over the past six months, we have accumulated a valuable set of lessons while taking stores into production. During this period, we have learned what to avoid, what doesn't work, and the best way to start developing an online store. Below, we share a summary of the lessons we have acquired during this journey.

Starting the Development of a Store

All projects created at Deco start from a pre-configured template with various components, integrations, and themes. We have noticed that after creating the store, some developers turn to GitHub to modify components and themes directly in the code. Although this is a natural reflex for a developer's work, we have noticed that projects in which development mainly focuses on the CMS (Content Management System) tend to be completed more quickly and with better performance.

The ideal flow that we have discovered is as follows:

1. Create the project.
2. Customize the theme, components, SEO optimization, among others through the Deco admin.
3. Present the result to the end client and collect feedback.
4. Based on the feedback, adjust the store in the CMS, using the predefined sections, and return to step 3.
5. If the client is satisfied, migrate the domain to Deco.
6. If it is necessary to make changes in the code, add specific sections for the use case in question.

The <dialog> Tag

In previous versions of our templates, we used the HTML5 tag <dialog>. This tag allowed the creation of modals with accessibility support. However, we identified two main problems related to it:

1. It required JavaScript to work properly, which went against our philosophy of minimizing the use of JavaScript on the page.
2. Recent versions of iPhones (10, 11, and 12) do not support this tag, which forced us to insert "polyfills". This insertion was synchronous and significantly affected the performance of the websites.

Due to these two mentioned points, we have adopted an alternative approach using the <input type="checkbox> tag, which is widely supported by all browsers. This change solved both problems. We migrated our templates to this technique and observed an increase in compatibility between our websites and mobile devices.

If your website is still using the <dialog> tag, we recommend migrating to <input type="checkbox> as soon as possible to avoid incompatibilities with iPhones. For more information about this approach, please refer to this link.

Absolute Units

We noticed that some of our stores had conversion rates below expectations on certain devices, especially iPhones and Android devices. After a deeper analysis, we identified that the "Go to checkout" button was being hidden by the browser's address bar in Chrome and Safari on some of these devices.

This problem occurred due to the use of absolute units, such as vh (viewport height) and vw (viewport width), instead of relative units. Absolute units refer to the total size of the device's screen, not taking into account the rendering area of the window, which can hide parts of the user interface.

To avoid this type of problem, it is essential to avoid the use of absolute units such as vh and vw. We recommend reviewing your store to ensure that these units are not being used, especially in the minicart.

Flexbox and Percentage Units

Another problem that we identified in some stores relates to broken layouts in older versions of Safari. This usually occurs when percentage units are used in conjunction with flexbox. An example of this is the following code snippet:

<div class="flex">
   <div class="w-full"/>
</div>

In this example, we are combining flexbox (class flex) with percentage units (width: 100%). This may work in newer browsers but causes issues in older versions of Safari, such as iPhone 10, 11, and 12.

To solve this problem, we recommend replacing w-full with classes related to flexbox:

<div class="flex">
   <div class="flex-grow"/>
</div>

This will ensure that the layout works correctly in all browsers.

We are always keeping up with new projects, collecting feedback, and improving the Storefront template.