Conversation
| } | ||
| ``` | ||
|
|
||
| Lastly, sometimes there is already a context opened when calling this middleware (e.g., there is another middleware that opnens such context). To support it, we call `getFields` and add the returned object to the fields: |
There was a problem hiding this comment.
opnens -> opens
Perhaps swap "a context opened" for "a context created" and later "accesses such a context". You would open a file but create a context (object).
There was a problem hiding this comment.
I have replaced the word "open" with "create" but...
Technically is not the same to create a context and to (???) (not sure which verb should be used)
For example in React you have React.createContext to create a context but then you have YourContext.Provider, a component that "???" (what should be the verb here?).
YourContext.Provider has two arguments: value and children.
valuein React isfieldsin Skogchildrenin React isfnin Skog
The context is created by Skog. What we export is a function that provides the value to the context. The context is (???) by the user.
There was a problem hiding this comment.
Good point! Perhaps read or access the context object? Open would imply that you need to close it (file/connection). And create as you say implies that it is instantiated.
There was a problem hiding this comment.
Another option is just to omit the word context at all since it is an implementation detail and instead rename the function runWithSkogContext -> runWithSkog or something...
And in the documentation refer to such function as "context provider" maybe...
| ...getFields(), | ||
| req_id: nanoid(), |
There was a problem hiding this comment.
This opens up to name conflicts (which is the major complaint with the context approach in the first place). Perhaps consider mentioning this or allow a way to handle naming conflicts.
There was a problem hiding this comment.
True. And returning to the analogy with React Context, it has the same problem. I will try to mention it in some understandable way...
2 participants
This PR creates some documentation documents about Skog.
It adds documents about concepts, not any exhaustive documentation. Focus is understand Skog and understand why is it designed how it is designed.
Tip for review: Recommended to go to read the docs in the branch instead of the "Files changed" tab