Current JavaScript strategy
For the first production ready release of the Digital Framework a strategic decision was made early on not to provide JavaScript support. There were several reasons for this:
- We didn't want to assume what functionality teams across the company needed, we needed requirements and that was a larger piece of work.
- We didn't want to break applications because of poor JavaScript decisions made without understanding use cases. There are numerous versions of open source frameworks in use across the company, we need to understand how to inter-operate if need be.
- We didn't want to release a poor quality solution. If using a shared, reusable JavaScript library, it has to be as good as it needs to be e.g. built with the right technologies, tools, good patterns, well governed, documented, tests etc. More importantly, it needs to be done collaboratively.
- We did want to support as many platforms in Standard Life/Phoenix as possible and not limit a Version 1 release due to a JavaScript dependency we chose.
- We aimed to build a Digital framework that is robust and extendable, meaning we can more easily add on JavaScript support in the future.
- We did want to offer an optional JavaScript support in the first release (though not recommended)
This doesn't mean there won't be JavaScript support in future releases, it is on the road plan and work will begin to understand the scope of the requirements soon. This will be a collaborative process and we will be asking for help and contributions as well as sharing decisions and progress.
JavaScript usage
We should be clear on what use cases you'll need JavaScript for with a CSS only framework. Mainly these are for user event driven user interface "widgets" such as menus, accordions, carousels, popups/overlays etc.
There are also use cases for non widget type code such as the cookie policy and possibly smaller concerns such as analytics.
With the current Version 1 release there are two ways you can add UI driven JavaScript functionality on your website.
1) Custom written JavaScript
This is currently the recommended approach, however you will need to write some boilerplate code yourself which we will provide examples of TODO .
This functionality is achieved using simple show/hide type CSS classes applied via your own JavaScript code. The boilerplate code you need is a simple adding/removing of classes to and from DOM elements. We provide those CSS classes as an API standard, they are documented on each component in the styleguide. We will document any and all changes to these CSS classes.
How to use the styleguide for JavaScript
For every component which has some type of extra JavaScript functionality, there is a section named "JavaScript Support" which will list the CSS classes you can use and their purpose.
Look for the "JavaScript Support" section e.g. for the modal component
JavaScript Support
| JavaScript Support class name | Description |
|---|---|
slb-show |
Add the show class to the modal container to display the modal, removing the class will display nothing. |
As described, this instructs you to add this class name to the DOM element to show it, removing it will hide it.
2) Boostrap JavaScript
This is not a recommended solution. It can be used and it's what's being used on the styleguide for simplicity. We offer optional JavaScript support through using the official Bootstrap JavaScript library. This is because the framework is built upon Bootstrap and follows the same markup patterns/structure.
This means you can use it both programmatically and declaratively (data attributes).
Please see the official documentation at https://getbootstrap.com/docs/4.3/getting-started/javascript
Future JavaScript strategy
There will be more to come from this considering the possible UI architecture work.