Core and extended functionalities

You might have noticed in the styleguide navigation and on the mega T1 index page some CORE and EXTENDED suffix are sometimes added behind a functionality/component. What they mean is the main subject of this documentation page :-)

Core functionlities

What the CORE suffix means when added behind a component name/functionality is that it is re-usable for other projects/third parties(NMSCs, carconfig app, customer portal, etc...). Of course, for script dependent component, this doesn't mean the resource can be accessed and manipulated however the third party wants, the access and commication to those kind of components is explained in here.

How to use a CORE functionalities

Basically, the core component is build and maintained by the client marketing project. The core component has a base HTML structure which can be re-used by third parties. The styling of this component and, in some cases, script handled features are handled by marketing.

For instance if this following button is added as a CORE component:

<button class="core-button">
    A basic core button

Any future changes to it shouldn't impact third parties in a non-expected way(e.g: adding some spacing rules to the button..., changing the class to button-core, etc...). If there's a risk and that the change has been requested(CHANGE REQUEST), a clear commication should be done and agreed with the Project Owner or Client in charge so that everyone can adapt in time.

On the other hand changes, coming from a change request, like the following ones:

Should normally not impact other projects in a non-expected way and can be done without any updates from their side...

Script dependent component

Some component that are script dependent can also be re-used by third parties, but like previously explained, the functionality access and communication is limited by our standards.

For instance if a third party wants to re-use this overflowable row component all they will have to do is re-use the html base structure and the script behind will be entirely handled by marketing. To share state changes of the component, postal events you can subscribe to are available. As for triggering some component functionalities on the component itself, unlike regular plugins exposing functions, the same event driven approach should be followed depending on what is supported: publish a postal event with the correct data for triggering the component functionality.

NOTE for third parties: when subscribing to those events, the marketing postal syntactic sugar t1.channels.nameofchannel.subscribde / t1.channels.nameofchannel.publish should of course not be used by third parties. The same rule also applies to t1.constants.nameOfEvent: third parties should use native postal events and the communicated value for the event name/channel name(e.g: "").

Extended functionlities

Functionalities other than CORE ones, even if not explicitly mentioned, are all extended ones that only marketing can use.

The reason why not everything is CORE and re-usable is simple: the application is updated on each release(at most every three weeks) and directly impacts projects that are dependent on it without them having the choice to avoid those updates. So, unlike plugins where you can manage the version of the dependency, the application you rely on is a real-moving target: making everything re-usable is just not going to work or is going to make code flexibility VERY limited. That's the reason why a lot of functionalities aren't CORE.