Skip to content

Module System Enhancements #118

@rafd

Description

@rafd

Braid's code base is organized around "modules" (more about modules here ). How modules work in Braid has been iterated upon multiple times and will likely continue to evolve.

This issue and related milestone will track the ongoing effort to improve the module system.

Module Wishlist

  • should make use of built-in clojure as much as possible
  • module should not be aware of other modules that are extending it
  • should be clear what is available for use and for extension (what is "public" vs "private")

v0

  • a module can expose functionality ("the provider"), which another module can use ("the consumer")
  • a module can be both a provider and a consumer
  • the provider does not know about the consumers
  • a module can span across client and server

v1

  • a dependency graph can be generated
  • modules can easily spec required inputs/outputs
  • API docs for each module can be generated, ex:
xyz-module
depends on: 
"foo-event", 
"bar-event"
provides: 
"baz-event" params, docstring, expected return value
* [ ] unit tests can be defined per module
* [ ] e2e-tests can be defined per module

### v100
* [ ] modules can be turned on/off (via UI or system config)
* [ ] modules can be defined across repos (ie. for now, it's fine to have everything in a mega-repo)

## Potential Inspiration:
* ring pipeline / middleware
* re-frame events
* robert-hooke library 
* DOM event system
* component 
* mount
* defmulti
* pubsub

Metadata

Metadata

Assignees

No one assigned

    Labels

    ongoing-effortA major initiative spanning multiple tasks.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions