Development workflow

Environments

Styla does not offer traditional dev/staging/prod environments as such. Instead, you can work with the following methods to achieve real-world testing without risking unrefined code on production websites:

A staging front

At no extra charge you can create a new front called [frontname]-staging in the client's organisation. This front can be connected to a staging BigCommerce instance and be used for all testing and development efforts by a developer or an agency. The front will run on a Styla staging domain (but running on the Styla production system without affecting a client's production storefront).

Here you can test and play at your heart's content without affecting the live storefront. Once code, settings, styling or a custom module is done and tested you can simply copy it over to the production front.

A test page

Open

Set the No-index option to true to keep the test page undiscoverable.

For some development of custom modules or HTML modules, it might be enough to create a new test page on a production front and set the noindex page option to true in the settings tab. It will get published, but will stay undiscoverable, as it won’t be linked to automatically. You can add your custom module here and test it. Once it’s finished, you can add the custom module to real ‘live’ pages or bases.

Make sure to clearly name your page as test page, note who is using it for testing and ideally delete it after your work is done and moved to a live page.

Dev Workflow

The recommended workflow to develop custom modules is as follows.

1. Define your module schema structure, and upload it to your hosting service (S3 bucket, FTP etc.)

2. Go to the Organization Manager → Front Configuration

3. There, add the Custom Module definition.

   1.  type, title and schema are expected.

   2.  template and js can be omitted for now.

4. Log-in into the Editor and create a new sample test page. Your Custom Module should now be available in the list of available modules.

5. Drop it in the page and insert some data.

6. Now create a .handlebars file. In it, you can now use references to your custom data, based on your schema configuration from Step 1.

7. Upload the handlebars file to your hosting service

8. Update your Custom Module configuration (Points 2 & 3) to target this file (under template)

9. Refresh your page in Editor. In preview mode, you should see the output of your module. Altering the dynamic data on the Editor panel will automatically update the preview. You can also publish and see your custom module rendered in the generated page.

10. If the module doesn’t use dynamic JS, the procedure is complete. Otherwise, repeat from point 6 to 9 but this time with the js file.

For more details, see https://styla.atlassian.net/wiki/spaces/FD/pages/1400242186 Documentation.

Hosting

The files for custom modules should be hosted on your publicly accessible file hosting service (S3 bucket, FTP etc.) For the production front, we recommend putting a CDN in front of your host for speed optimisation.

Editing & versioning code

We recommend working in your favourite code editor and version your code in your own repository on your favourite file versioning solution. You can update the files hosted on your hosting service as per your usual development workflow. Styla will always pull in the latest version of your file at the time it is needed The Handlebars template is only used during server-side rendering time, but the JavaScript file is loaded by the visitor in the browser when they load the page. Be sure to keep the two files in sync and compatible with each other. This may mean re-rendering the page when a new version of the Handlebars template is available, before updating the JS file. Be sure to consider your host's file caching policy when wondering why an update has no effect.