Managing state is hard. Delta aims to make it simple.

Currently involves a good amount of setup which I'd like to minimize if possible. It does make it very configurable and a very simple framework at this point which doesn't have to maintain much.

We pretty much defer to whatever the Rx implementation the user uses but so they'll have to extend it to make it conform to the protocol.

Definitely needs docs an examples which I'd be happy to write more of once we solidify the API a bit more and decide how much this lib needs to do vs. using an Rx implementation.

Having an API for adding middlewares to intercept dispatches and do something else seems like it could be useful.

A few examples I think this could be nice for is:

1. Tracking analytics as a side effect of dispatching an event.
2. Tracking actions for #19
3. Debug tooling that can see what's being dispatched and do something with it, like log the action

Thoughts?

Another attempt at middleware. I had to make Store its own concrete structure so it could store currently registered middleware. Maybe it makes more sense as a final class.

A Middleware is a function that takes the current state value stateValue, and a () -> Bool function next.

Middleware is executed sequentially in the order it is registered. The next middleware is only executed if the previous returns the result of next() at the end. If it returns false, the state will not be updated. If it returns true, the state will be updated immediately without executing the remaining middleware.

See the StoreSpec for a super basic example.

I still don't think this is the final route to go, but I think I'm getting closer. Ideally, Middleware would also take the action being dispatched. But unfortunately that's not currently possible because we can't add generic constraints to a typealias (currently Middleware is just a type alias). I think there's a way to get around this, but I haven't cracked that yet. Going to keep fiddling.

Tracking changes aka time travel debugging #19 will be difficult. Because Swift doesn't have higher order types, there's no way to store a collection of type-constrained, protocol conforming structures of different types. In other words, even though the reduce for every ActionType associated with a particular store has the same signature, the structures themselves have different types, so they can't be stored side-by-side in a collection.

One way we might be able to get around this and still have valuable information about mutation is by reflecting the action and initializing a Mutation structure, containing the stringified action type (e.g. "SetCurrentUserAction") and that actions stored properties (e.g. ["user": User(name: "Jane Doe")]). This would give us the same valuable information and we'd be able to store these concrete Mutations easily

Protocols that describe what something is should read as nouns (e.g. Collection). Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

https://swift.org/documentation/api-design-guidelines.html#be-grammatical

Jazzy docs

• [x] Add section about using an Rx implementation
• [x] ~~Example repo? OSS constable?~~ let's strike for now to get this done. Constable is probably a good choice eventually
• [x] Definitely needs edits
• [x] Don't end in blah blah blah
• [x] Move getting started to it's own page?
• [x] Link to jazzy docs
• [x] Reword async action type stuff to match dynamic action

closes #16

Reopening since the issues -> PR conversion lost the original issue

Having an API for adding middlewares to intercept dispatches and do something else seems like it could be useful.

A few examples I think this could be nice for is:

1. Tracking analytics as a side effect of dispatching an event.
2. Tracking actions for #19
3. Debug tooling that can see what's being dispatched and do something with it, like log the action

Thoughts?

Original issue: https://github.com/thoughtbot/Delta/pull/20

Now that we have a sweet name like Delta, we could use a nice logo for when we OSS this. Any designers interested in designing one?

cc @thoughtbot/design

Why:

• Store class syntax was a bit gross and protocol extensions!
• Too much boilerplate #4

This change addresses the need by:

• Adding a StoreType that you implement on a store struct. It contains default implementations for dispatching.
• Randomly come across the fact that implementing the reduce method on the ActionType infers the typealias

The only required setup you need now is:

struct Store: StoreType {
    var state: ObservableProperty<AppState>
}

Edits: Changed setup to remove redundant typealias

Hi, I am trying to add this Delta branch to a Swift 3 project I am working on. The Delta.framework is linked in the project and is seen where 'imported'.

What occurs though is when I attempt to build and run to the Simulator. Up to now, my project ran on the Simulator with no warnings or errors.

The compiler error I get is: dyld: Library not loaded: @rpath/Delta.framework/Delta Referenced from: /Users/mikenorman/Library/Developer/CoreSimulator/Devices/1EB55262-AAA4-41D4-892A-7E958D1CB515/data/Containers/Bundle/Application/836A24C4-D6AF-4900-92B6-9722B998F615/trips.app/trips Reason: image not found (lldb)

Any idea of what might be causing this? I am also looking on Stackoverflow for similar issues.

Thanks

--mike

• Created a hierarchy for tests
• Renamed a couple test files
• Renamed ***Tests to ***Spec, including QuickSpec subclasses
• Fixed the reference to Delta.xcodeproj

This might be pre-emptive, but any ideas for a Source file structure?

Any opposition to using Quick/Nimble?

I'd also like to write some more extensive tests, especially with consecutive state changes. A good example in one of the FB flux videos is (I'm paraphrasing):

You have a list of active users [Mary, John, Kate]:

1. George becomes active
2. Mary becomes inactive
3. Tina becomes active

Now what does the list of active users look like?