npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@oikio/clean-architecture-fe

v0.0.3

Published

This is an example of "clean architecture", which can be used across frontend projects of any size and technologies. This repository is an implementation and example of the idea, so everything from FRP to view libraries are just implementation details.

Downloads

7

Readme

Concept

This is an example of "clean architecture", which can be used across frontend projects of any size and technologies.
This repository is an implementation and example of the idea, so everything from FRP to view libraries are just implementation details.
I'm quite familiar with React and FRP, that's why my example is built on top of these technologies, but you can use anything as long as you follow this:

Diagram

State

State can be a stream or group of streams.
StateUpdaters are dumb store updaters.
StateUpdaters should work only with their own Cell.
Selectors are optional, you might not need them because you just use streams which you need.
Selectors should be part of State.
ComputedState (DerivedState) can be a stateStream without stateUpdater, or function which will return parametrized stream.
ComputedState should be simple, otherwise create useCase -> state pipeline.

Dispatcher

Dispatcher provides dispatch method for intents.
Dispatcher can be a stream of intents for useCases.

Intents

Intents are dispatching events to Dispatcher.
They are the only way to update useCases and can be used in top layer of application (in Components, Services, Router and etc).
Intents only update related useCases.
One UseCase can has only one Intent.

UseCases

UseCases are streams, which might be subscribed to Dispatcher.
UseCases can be reactive for anything provided in SideEffects (e.g. reaction on state change without dispatcher).
UseCases can dispatch action or use SideEffects.
UseCases should contain just business logic.
UseCases should know nothing about outer scope, but contracts.
UseCases can invoke intents, but try to keep it inside one domain of useCases.
If you want to use libraries like validation, ajax and so on inside useCases, use, but treat them as contracts then.

Components

Components can only use intents to interact with outer scope.
Outer knowledge should only come from state or computedState streams.
Local state is appreciated, if it's related to view.
Components can be from any library, I will use React, but it's an implementation detail.
Reusable components should be in components folder, routes in routes folder.

Gateways, services and etc

Should only be invoked in useCases as SideEffects.
Can use Intents to invoke useCases.

Utils

Pure functions, which can be grouped and used across the project.

To run app

npm i
npm run dev

TODO:

Create a real simple app (form, filtering, complex state)
Add tests (ava + jest? e2e?), see how they should work with useCases and components.
Add hydration of state example.
Add time travel example.
Add computed state example.
Add cancelable useCases.
Create more complex app, maybe just develop a list of howtos.