Clarification on repo purpose and constraints #14
Description
👋 Hello! Since we already have a few contributions to this repo I'd like to get some clarification on its intended purpose and define some bumpers for our code bowling 🎳
Purpose
Looking at the list of components in the Roadmap, I get the feeling we want to create a repository of functionality rather than a fully dressed and production-ready component; more recipe book than buffet. Is this a correct assumption?
Constraints
Assuming this repo is meant to be a copy/paste starting point that can plug into any existing app-web project, I offer the following Contribution Constraints For Consideration (CCFC™):
No global utils
Unless we also want to make this a utils starter repo, any utility functions used by components should be housed within the component directory itself. This allows total portability when copying a component directory into another project. It is then up to the implementor to decide whether a local util can/should be replaced with something that is more global in their project.
No external dependencies for styling
To make this truly style agnostic, we should keep external dependencies related to styling out of the picture (including classnames) and either import CSS the old fashioned way or write style props. These components will be massaged into some other design system, so styling shouldn't be a priority aside from supporting structural/layout rules.
Controlled Components by default
Since we can't make assumptions about how state is managed in the destination codebase, we should always offer a way to manage the state of these components externally. Pagination and Tabs, for example, are both components that might make sense to manage their own state out of the box for ease of implementation. However, both of these can be tied to a router, redux, or some other higher level state that needn't be reimplemented. It's simple enough for the implementor to wrap these components to provide state, given we provide a clear way of doing that within the component design. Therefore I propose we reserve internal state management for essential operations only, such as transition/animation hooks.
No cross-dependencies
In the case where we'd be tempted to use a crema-component within another crema-component, we should opt to use a primitive default and offer a way to pass in an overriding component. This way, the implementor can either modify the pasted code to use components in their codebase or wrap the crema-component in something that passes in elements native to their codebase.
Conclusion
Since a lot of production projects will end up using an existing, robust UI library, it seems best that this repo be a place to get a bare-bones version of something to mold to other specs. Here is the microphone 🎤, please speak your thoughts into it and also write them down.