A project to aggregate and develop high-quality, community contributed Solid primitives, components and directives. All utilities are well tested and continuously maintained. Every contribution to the repository is checked for quality and maintained by the highest degree of excellence. The ultimate goal is to provide a properly reactive layer for browser APIs and common helpers.
The goal of Solid Primitives is to be an official aggregation of utilities that wrap core logic on the client and server. Each primitive is designed to act as a building block or keystone, the goal being to DRY up source as much as possible and fit together logic as a compact system of parts.
Ultimately the more rooted these primitives are, the better they act as foundation within Solid's base ecosystem. With well built and re-used foundations, the smaller (aggregate tree-shaking benefits), more concise (readability) and stable (consistent and managed testing + maintenance) applications can be overall.
Other frameworks have large and extremely well established ecosystems. Notably React which has a vast array of component and hooks. The amount of choice within the ecosystem is great but often these tools are built as one-offs resulting in often un-tested logic or are designed with narrow needs. Over time the less concise these building blocks are the more they tend to repeat themselves.
Our goal with Primitives is to bring the community together to contribute, evolve and use a base set of foundations in their work. The more we work together, the stronger and richer of an ecosystem we can build and the more we all benefit.
We aren't trying to replace the ecosystem of React and other libraries with a monosolution, but merely offer a consistent and tightly defined set of tools. A community ecosystem will and should continue offering alternatives to expand a users choice. It's this fine balance we as maintainers of Primitives need to juggle.
All Primitives packages follow a single consistency and promise. We guarentee that each is created with the utmost care, providing primitivates that are:
- Documented and follow a consistent style guide
- Be well tested
- Small, concise and practical as possible
- A single primitive for a single purpose
- As few, if none, dependencies as possible
- SSR safe entries provided
- Wrap base level Browser APIs
- Should be progressively improved for future features
- Be focused on composition vs. isolation of logic
- Community voice and needs guide roadmap and planning
- Strong TypeScript support
- Performance!
Each primitive is designed with composition or segmentation in mind. To align with the goal of being small and concise a major rule to designing our primitives is deciding if the interface for primitives should be: composable or segmented. For this reason every API is intricately studied and considered to be composed (stacked with features) or composed into smaller units.
Designing our primitives in this manner allows for better tree shaking and very layering complexity as needed. Only ship what you have to by picking from existing primitives as your foundational building blocks.
- createAudio
- createMediaQuery
- createRAF
- createResizeObserver
- createIntersectionObserver
- createStream
- createDevices
- createMicrophones
- createCameras
- createSpeakers
- createAmplitudeStream
- createMediaPermissionRequest
- createPermission
- createDragAndDrop
- createPageVisibilityObserver
- createFullscreen
- createBattery
- createAccelerometer
- createGyroscope
- createStorage
- createLocalStorage
- createCookieStorage
- createSessionStorage
- createGeolocation
- createEventListener
- createURL
- createClipboard
- createHistory
- createLocale
- createFetch
- createWebsocket
- createGraphQLClient
- createNotification
- createPush
- createConnectionObserver
- createScrollObserver
- createGesture (in progress)
- createKeyboard
- createForm
- createTouch
- createThrottle
- createDebounce
- createTimer
- createCountdown
- createTween
- usei18n
- createWorker (in progress)
- createQueue
- createDateDifference
- createEffectWhen