Thoughts on Context

@christianalfoni Just iterating on context type.

First I think it could make sense to use the notion of Context for the operation argument like we used in Cerebral. So no more effects.

type BaseContext<App> = App['context'] & { state: App['state'] }
type Context<App, Value> = BaseContext<App> & { value: Value }

And we get back what we had:

// Manual Config definition
export interface Config {
  state: {
    foo: string
  },
  context: { // instead of `effects`
    http: {...},
  }
}
export type App = TApp<Config>
export type Action = TAction<App>

Action definition:

const foo: Action<string> = action =>
  action
    .map(({ http }) => http.get(...))
    .mutate(({ state, value }) => (state.foo = value))

We just have to be careful as to how we construct the App type (by hand or by inspection of the config) to avoid context = any.

I also think it would make a lot of things simpler in overmind types if we passed BaseContext around instead of Effects and State.

[christianalfoni]

Very nice summary!! 👍

Solution (1) Even though this is straight forward, I do not think it is the way to do typing. It would be like doing:

const MyComponent = (props: Props) => ()

Where you should do:

const MyComponent: React.SFC<Props> = (props) => ()

Now React know that MyComponent is a component, not a function with arbitrary typing on its argument. The same should be for operations. Overmind benefits from knowing that the function you compose in is of an actual operation type, not just an arbitrary function with some typing on it. “Typing on the left, implement on the right”. Also you get more help in terms of expected return type etc.

Solution(2) This is what we did previously as well. It just really annoys me that we have to do it that way, which is why the “hack” came up as a suggestion 😃 What I like here though is that you have improved the typing since last time. So copy pasting this feels better than the previous one 😃

Solution(3) It is really good to have the suggestion up here, though yeah… I feel this makes Typescript define the API, instead of Typescript just being sprinkled on top of existing API.

You know… my conclusion after seeing this is that I think the cleanup you did with types in solution2 has made it OK 😄 Just copy paste that typing and you are good to go. That is the most correct way to do it for sure… and who knows, maybe namespaces will get generics at some point. Then we can clean it up even more.

So yeah, I vote for solution2 as the one and only solution 😃

[abalmos]

I agree that TypeScript ugliness shouldn’t stop Overmind from doing The Right Thing (when is it not ugly anyway?). I have limited TypeScript, but it seems people have accepted they will need to do something in order for a new dependency’s types to work.

That said, could all this be put together in a way that Overmind is TypeScript compilable without that wall of copy and paste, and then useful with it?