Extensibility

To stay "pluggable" the architecture must be highly "extensible". Consider the following recommendations while implementing an application:

• Use classes for multi-part, complex feature implementations. Classes allow isolating functionality under the shared context while splitting the functionality into logical functions. For example: React components, GraphQl query-builders.

• Use functions for single-purpose, isolated feature implementations where context sharing is not required. For example request and data processors, utility functions.

To allow plugin nesting (stacking), the data-structures for class members and functions must be carefully chosen according to the following guidelines:

• For a list of conditions resulting in different outcomes use maps or objects. Try to avoid "if-else" or "switch" cases as they are tougher to read and extend.

• For a list of items dependant on order or "SortedList" utility from @scandipwa/framework/src/util/SortedMap. Try to avoid objects as they do not guarantee the proper sorting of entries, and arrays as they do not expose a way to insert after or before a specific entry.

• Try to avoid returning complex values (objects of a class) if possible. The common complex values are: React elements, GraphQl Fields. For example: instead of returning a wrapper with rendered items in it, consider splitting that logic into smaller parts:

  • wrapper rendering function

  • a function returning the array of items wrapped by a wrapper

  • a function for each wrapped item rendering

Read more on Extensibility in the documentation.