FROK scope
Which components and what kind of functionality a FROK component can have, will be explained in the following. This should help do decide if a component gets develop as FROK component or needs to be developed by the projects itself.
Framework usage
The originally goal the Frontend Kit component library was to provide framework agnostic components, which are represented by Markup and CSS only. This goal is still valid and will be the most crucial factor to decide, if a component is in scope of the FROK.
Data Fetching and other attachment for data sources
FROK will not make any decision or prediction how data comes into the given project, application or component. Therefore all data fetching or data receiving logic will not be included in FROK component.
Also render logic which is based on receiving data, e.g. receiving data and render a list of items from it, is explicitly not part of any FROK component.
Complexity of components
In modern applications components often holding some kind of state. FROK components try to have as less as possible state management inside as possible. E.g. an audio or video component are holding state, but only for the UI elements.
Other states provided for example by some kind of global context, are deliberately not part of each component.
When a component needs more state management that are way easier to achieve with framework specific techniques, this component is more likely not part of the FROK.
Relevance of the component
For a component to get integrated in FROK, it should have more than one use-case. Components that are very specific to one project or context, are most likely not adapted as a FROK component.
Conclusion
characteristics | FROK adapatable | not FROK adapatable |
---|---|---|
framework | no framework needed to build component | is easier build with the use of framework functionalities |
data | no data fetching rendering is needed to build and run the component | data fetching and rendering are a key feature of the component |
complexity | reasonable amount of logic is used to build the component | complex state management is needed to achieve the component features |
relevance | more than one use-case, component can be used in a variety of projects | very specific project use-case, component is only relevant there |