<commit_before># Gooey

> PubSub data delegation solution for ES6 Single Page Applications.

## Features

* Hierarchical, bi-directional, acyclic event broadcasting
* Services as proxies (data can be safely mutated before being handed off to next service, great for pipelining)
* Pattern-matched subscriptions (in other words, subscribe to changes via JsonPath)

## Goals

* Reactive (no polling, hence PubSub)
* Flexible yet predictable pipelining of events
* Canonical source of data (encourage accessing data from service as much as possible)
* Transparency over common concurrency pitfalls such as deadlocks, livelocks, race conditions, etc.
* Functional parallelism (pure functions with immutable arguments that are parallelizable)
* Minimally invasive (choose when to use it, plays nice with others)
* Easily extensible to allow for new Services such as URL, REST, DOM, etc.
* Simple configuration model (root defines globals, all other child services may override)
* No shims other than Babel - it's time to move forward.

## Model



## Installation

> $ npm install

> $ gulp install

## Testing

> $ gulp test

## Examples

## Troubleshooting

## TODO

- [ ] Depth-first Down Traversal (in prog.)
- [ ] Depth-first Up Traversal
- [ ] Breadth-first Down Traversal
- [ ] Breadth-first Up Traversal
- [ ] Concurrent traversals
- [ ] Sibling collisions (Up direction)<commit_msg>:scroll: big readme update (diagrams and such)<commit_after># Gooey

> PubSub data synchronization solution for ES6 Single Page Applications

Single Page Applications (SPAs) have a dynamic context of components that continually changes based on a user's interactions with the system.

Synchronizing the data between the components and layers of this dynamic context is one of the greatest challenges
facing complex SPAs.

Gooey aims to ease the management of complex cross-stack components by making the task more centralized, pragmatic, and responsive.

## Problem

Suppose you are designing an online portal for a company that finances renewable energy systems.
You might represent your model components as a composition hierarchy:

                                       User
                                        |
                         +-----------------------------+
                         |                             |
                         v                             v
                       Quotes                       Proposals
                         |
         +------------------------------+
         |                              |
         v                              v
      Systems                   Finance Products


In this architecture, the User component is essentially acting as the canonical context of the application since all other
model components depend on it.

Assume that a User can be viewing either one Quote or Proposal at a time. If a Quote is selected,
then the User must also have one System and one Finance Product selected.

What can make this simple yet dynamic context difficult to manage? (Examples represent potential future requirements):

 - Component states are often decoupled and split across layers of the stack
    * Example: The state of the User and its dependent components must also be synchronized with the the view and the API
 - Strong coupling between components (components expclitly reference and depend on each other)
    * Example: If the address of a User's only Quote is changed, reflect the change in the User's primary address as well
 - Distant interdependencies between components
    * Example: If a System reaches a "finance ready" state, the Quote now needs Documents which the User can sign. User can't interact with other parts of the application until they sign or reject the Documents.
 - Difficult to synchronize effects and limitations of errors between relevant components
    * Example: If a Finance Product component experiences a 500 error, ensure that User can no longer access the Quote and, if possible, re-select a new Quote for the User.

The mechanism of data synchronization and "binding" in modern JS frameworks is often re-invented and sometimes implemented with
inefficient and bug-prone solutions that emphasize dirty-checking.

## Model

Gooey loosly follows the [Composite Pattern](https://en.wikipedia.org/wiki/Composite_pattern) and represents data components as canonical `Services` that
can subscribe and publish data.

`Services` have a 1:1 relationship with an optional parent Service and a 1:N relationship with optional child `Services`.

These relationships naturally establish a tree data structure that can scale to support any number of `Services`:


                (?) Parent Service
                        |
                        |
                     Service
                        |
         +-----------------------------+
         |                             |
         v                             v
    (?) Child Service A           (?) Child Service B


`Services` that form this tree can publish data to each other bi-direciontally. Gooey supports several
traversal patterns for data publication but performs breadth-first down by default.

Because `Services` can communicate with related services bi-direciontally, they can be extended to support the components
of a modern SPA:


                (?) Rest Service
                        |
                        |
                     Service
                        |
         +-----------------------------+
         |                             |
         v                             v
    (?) View Service A         (?) View Service B


However, this design is out of the scope of Gooey core and will be in a module of its own.

### Summary

* Publish / Subscribe
* Hierarchical
* Bi-directional
* Acyclic
* Canonical instance
* Pattern-matched events
* Nodes as proxies (data can be safely mutated before being delegated)

## Installation

> $ npm install
> $ gulp install

## Testing

> $ gulp test

## Contributing

Gooey is still in its very early stages. Please feel free to message [<EMAIL>](mailto:<EMAIL>) if you are interested in contributing!

## TODO

- [X] Depth-first Down Traversal
- [ ] Depth-first Up Traversal (in prog.)
- [X] Breadth-first Down Traversal
- [ ] Breadth-first Up Traversal
- [ ] Concurrent traversals
- [ ] Sibling collisions (Up direction)
{'fraction_non_alphanumeric': 0.06771406127258445, 'fraction_numerical': 0.0012568735271013354, 'mean_word_length': 2.3260188087774294, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 13, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 12, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '388132', 'n_tokens_mistral': 1526, 'n_tokens_neox': 1417, 'n_words': 742}