You can add or remove a CSS style on a component or element during runtime. You can use the $A.util.addClass(cmpTarget, 'class') method to append CSS classes and $A.util.removeClass(cmpTarget, 'class') method to remove CSS classes from a component or element.

And you can use component.find('myCmp').get('v.class') method to retrieve the class name on a component, where myCmp is the aura:id attribute value.

Here is an example to adding and removing Styles on a Component during runtime.

Custom settings enable you to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database.

You can control the visibility of custom setting by specifying it as public or protected. If custom setting is marked as protected, the subscriber organization will not be able to access the custom setting. If it is marked as public, then subscriber org can also access it.

There are 2 types of custom setting, List and Hierarchy. Once you create custom setting, then you cannot change the type (List to hierarchy or vice versa).

List custom setting provides a reusable set of static data that can be accessed across your organization to all user.

Hierarchy custom setting uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. In Hierarchy custom setting for logged in user, system first check user then profile and then org wide setting in order to return data from hierarchy custom setting.

Custom settings do not support relationship fields.

Custom Settings have the same permission to edit the records and to edit the configuration. Both can be done with the “Configure Application” permission.

You can access custom setting data using instance methods and can avoid SOQL queries to database.

While migrating custom setting to another org, It only deploys the metadata, you need to upload data into the custom setting post deployment.

Custom setting can be used by formula fields, validation rules, flows, Apex, and the SOAP API.

You cannot access List custom setting in Validation rule. Only Hierarchy custom setting can be used.

You can perform CUD (Create, Update, Delete) operation on custom setting in apex.

Custom settings are not visible in test class without “SeeAllData” annotation.

Custom Metadat Types :

Custom metadata are like custom setting but records in custom metadata type considered as metadata rather than data. These are typically used to define application configurations that need to be migrated from one environment to another, or packaged and installed.

You can control the visibility of Custom Metadata Types by specifying it as public or protected. If it is marked as public type, then anyone can see it. If it is marked as protected type, in the installed managed package subscriber organization, only Apex code in that managed package can use it.

You can create lookups between Custom Metadata objects.

Metadata Relationship provides the ability to add relationships from your custom metadata to other things in your app, such as other custom metadata, custom or standard objects and fields, and static resources.

In Custom Metadata, you can edit the records with “Configure Application” permission, but you require “Author Apex” to edit the configuration.