# Just some notes so I don't loose my ideas whenever I have them
## Higher concept ideas

### Plugins
Plugins are bundles of application logic that enhance the core framework.
* Have no UI representation or UI components, there're simply functionality to modify or extend workflows in the core framework
* Example: Plugin for complex workflow orchestration (think `redux-saga` on steroids) allows to define a series of tasks that need to run with side effects.
* Example: Plugin that communicates with a 3rd-party service like pusher to provide push integration.
* Actions dispatched by plugins should follow the naming convention `$pluginName/ACTION`

#### `reductor-plugin-workflows`
* Workflow => series of tasks
* Tasks can depend on other tasks
* workflows should manage task execution automatically
* task that can be performed in parallel should be performed in parallel
* all data manipulation is cached in the workflow before applied to the store
* Actions:
** `$workflows/WORKFLOW_START`
** `$workflows/WORKFLOW_FINISH` -> this is when the state transformations are applied
** `$workflows/WORKFLOW_FAILED` -> triggered when at leas one mandatory task has failed
** `$workflows/TASK_START`
** `$workflows/TASK_FINISHED`
** `$workflows/TASK_FAILED` -> should have a tag if task was mandatory or optional
* maybe allow for groups that can be recoverable: If a task fails but a prior task group executed
successfully we can resume workflow execution from that point.
* only one workflow at a time

### Blocks
Blocks are representational UI components (react components)
* Only rely on props and internal state
* Can register with the application to store ui state in the redux store (possibly under a root `ui` key)
* Should expose a set of css classes/hooks that allow for custom styling (we need to establish conventions here)
* Do NOT come wit any application logic like reducers, actions, etc.
* Can depend on other blocks. (block composition)
* Can NOT depend on modules, plugins or themes

### Modules
Modules are basically pluggable micro applications.
* Can define their own routes
* Can define actions, reducers, payload creators, meta creators
* Can contain UI components, that are not blocks (module internal components, HOC's)
* Can depend on plugins
* Can depend on other modules
* Can depend on blocks

### Themes
Themes are CSS/Less kits for reductor applications that should be easily interchangable to change
the look and feel of your application.

> Probably the hardest architectural part because we need to rely on common conventions
and find a model that works.

* Themes need to define what set of modules and blocks they support
* We need a predictable hierarchy, maybe BEM? Just M-B-S (Module-Block-State)? 
* Seriously have to think about that more ... maybe just keep it completely separate and have people who
use the framework to build apps worry about that. The only downside to that would be that we'd have to load
the complete stylesheet for the entire app at all times and can't do code splitting for styles. But then again
maybe that's not a big deal.
* Ideas needed here ...

### Dependency infrastructure
We need an infrastructure to manage dependencies
* All packages live in npm and need to follow a naming convention outlined below
* Manifest file on application, module, plugin, block level that defines the dependency
* Resolve strategy automatically builds full npm package name and uses npm install to fetch the packages
* Version conflict handling etc.
* This definitely needs more thought too ...

### Package name organization and community contributions
We need a guideline for package names.
* All community package names should be prefixed by `reductor-contrib-*`
* Type of provided functionality in package name: `reductor-contrib-module-*`, `reductor-contrib-plugin-*`
* Package names `reductor-*` are for core packages by the project maintainers

### Logger
* Framework should support multiple logger implementations that adhere to a commonly defined interface
* Logger packages should be prefixed with `reductor-logger-*` if provided by project maintainers or `reductor-contrib-loggger-*` for community contributions.
* Internally the framework should generate and process log messages through an injected interface and be action based and stored in the state. That will
allow for the logger modules to just observe the state and react to dispatched actions.

#### Unorganized :shit: & flash notes regarding the current logger
* TODO use a real enum for LOG_LEVEL
* TODO enable output to store instead of console
* TODO expose grouping functionality
* TODO LogGroup { id, headline, entries: LogEntry[] }
* TODO LogEntry { timestamp, level, message, data, groupId, groupPos , meta: {} }
* TODO TimerResult { id, comment, startTime, endTime, duration }
* TODO don't import full lodash library
* TODO allow for time/date/timezone customization
* TODO allow for custom log formatting
* TODO @@reductor/LOG_ENTRY @@reductor/LOG_GROUP @@reductor/TIMER_START @@reductor/TIMER_END
* TODO Appenders: are basically function that know how to process Logger actions.
* TODO Appenders would allow for customizable log processing (BugSnag, etc.)
* TODO Payload and MetaCreator to customize what/how data is represented in the LogEntry object