Skip to main content

What are Some General Best Practices for Developing on Arc XP?

Who This Is For

This is for client front end developers who are working to migrate their existing websites onto the Arc platform.

Best Practices

  • Keep your components small, give them a single purpose and make them as reusable as possible.

  • Consider ways you can extend your components to make more specialized versions of them rather than duplicating the components.

  • Keep a global stylesheet rather than a style sheet per component -- this reduces your chances of duplicate styles and will help decrease your overall payload size. If you do need to use component-specific styles consider using utility styling depending on the use case.

  • USE THIS
    
    <span class="some_label | bold">Lorem</span>
    
    <styles>
    bold {font-weight: 700}
    </styles>
    
    INSTEAD OF THIS
    
    <span class="some_label">Lorem</span>
    
    <styles>
    span.some_label {font-weight: 700;}
    </styles>
    
  • Use inline styles sparingly, these get harder to manage as you nesting components within each other. One exception is a component you want to enforce specific styles no matter the other component it might be nested within (ie a video player, custom embed or popup window may fall into this category). Utility styling is good for this too. It helps to be less casual with inline styling and is easier to track.

  • Maintaining consistent styling metrics lessen the need for slight style or pixel variation use cases. For instance classes that vary by just a pixel spacing or two rather than all components using a consistent set of pixel spacing classes like xs, sm, md, lg and xl.

  • Use custom fields to support dynamic appearance/content in your components rather than hard coding values. Set default values on as many custom fields as possible. Default values are shown in PB Admin when you edit the component and will not be used by component at runtime unless those values are saved on the component.

  • In building react components our design pattern recommendation is to create Functional Components (most desirable), then Classes and finally the use of React Hooks (least desirable). Functional components typically have the best performance, least side effects, and are easily maintainable in Fusion. If You Use React Hooks Make Sure They Are Using React.Memo in order to capitalize on the best performance gains.

  • Make any component that doesn’t need a client side refresh static. This means there will only be a server side render of the component and it will paint faster than a component that needs a client side refresh. Try turning off JavaScript in your browser to ensure your server-side renders are occurring as planned. Mistakes in a server-side render are quickly covered up by the hydrating client-side render.

  • Limit the number of content fetch/resolve calls within a component and avoid making multiple calls to the same content source in the same component. Multiple calls should be chained in a single fetch -- this can be expensive, but The Fetch Method Is Cached As Per The Content TTL.

  • Setup a linter for your project to help maintain a similar look and feel of the programming across your code base. This will enhance readability for all of the different developer styles.

  • Write unit tests for all of your components. This will help you catch problems as you start nesting components within each other and will give you greater confidence to commit your changes to production without worrying about unintended consequences, broken functionality or negative side effects.

Common Issues

  1. Performance is overlooked until right before launch. This typically causes a delay in the client’s launch dates.

  2. Values are hard-coded when they should be dynamically pulled from site properties or set by a custom field or used from the content source. This reduces the reusability of a component and means more developer work and higher bundle sizes.

  3. Large bundle sizes. This leads to unexpected AWS costs when the site launches.

  4. Large data payloads returned. Often times fields are being returned in the content sources that are never used. Sometimes multiple content calls are being made where only one.

  5. Benchmark site audits to check for things like SEO, best practices, data quality, accessibility aren’t run. This can lead to a decrease in SEO, decrease in performance, and missing or invalid content across the site.

  6. Unused static or third party resources or bloated resources included on every page. This increases the size of the page and impacts performance.

  7. Third party scripts are loaded when the component has not been rendered. For instance, if you have a video player and include the video player scripts even if there is no video player loaded on the page. Instead these scripts should be injected into the DOM when componentDidMount is called for the video player component.