Thoughts on Context
See original GitHub issue@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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:12 (8 by maintainers)
Top Results From Across the Web
22 Thoughts on the Power of Context | by Scott Jancy
Understanding context means that you will have a better sense of the opportunities they face, they will be empowered to offer new ideas,...
Read more >Contextual Thinking |
Instead, we tend to label people as underperformers. As a practical definition, we define contextual thinking as the cognitive habit of examining behavioral...
Read more >Thoughts on Context and Capabilities in Rust
Temporal Trait Implementation The syntax here representing that all of T 's context must live for 'static and must be able to be...
Read more >Write an effective context statement with easy tips
A context statement is a brief introduction about yourself that defines your obligations and responsibilities in the academic field, such as ...
Read more >VUCA unpacked (4) — Contextual thinking | by Theo Dawson
Contextual thinking involves a set of interrelated skills that increase the scope, depth, and accuracy of our understanding of issues, problems, ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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:
Where you should do:
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 😃
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?