Open NilsJacobsen opened 1 month ago
You mean how to extract this in Sherlock?I have two donuts. 🍩
= m.donut_count({count: 2})
Yep. Sherlock must have a way to extract declarations too/have a keyboard navigation thingy for devs to do it fast
I disagree on that.
A static string is a normal string without any declaration. This string can later be made to something more through editing and message function can then also consume variables through props, but specify that at "message create/extract" goes against our "first simple message" approach where we add complexity gradually through the message component and not upfront.
@felix.haeberle code will have this
<p>You have {numberPhotos} photos</p>
you need to extract {numberPhotos} in sherlock as a declaration
You can do this in the message component? Also its not that easy. You now also have to specify whether it is photo/photos in this string for example. You have to jump in the message component either way for that.
At first, I would default to "edit in message component", and only after people request more VS Code built-in functionality: build it.
that means that @nils.jacobsen needs to build a "extract declarations" feature into the message component
i leave it up to nils on what to do
Scenarios:
that means that @nils.jacobsen needs to build a "extract declarations" feature into the message component
Not extract, why extract? Just create a declaration and use it in the message. Please don't overcomplicate this UX with users who have complete different setup where it gets really hard to do this (extract) right across librarier and potentially across languages.
- Declaration is written in extractable message, get's lost when extracted.
Expected, how should Sherlock know?
- Dev wants to add a new declaration to m function ⚡️ this is not possible (it doesn't get in the ast, their expectation will be: it's passed in, why doesn't it work?)
Same as above
- Auto extraction would cause problems if it is not capable of doing this
No problem as it is just not supported and you have to go through it afterwards.
I still don't get why we should overload the complexity of a simple text extract / message create when this is expected to be gradually added and not upfront.
@nils.jacobsen Potentially a LOOM could help to understand your requirement more, or a small session in Around.
@nils.jacobsen correct me if my loom is wrong. we want 3 things:
https://www.loom.com/share/a73d0144b4324fdaa559a15dd568a686?sid=6a2f2868-77e3-447b-b3db-861183b3dbd1
Small addition on the loom:
https://www.loom.com/share/78f08810532b4b0996f2669a27d4897c?sid=1dae3b31-478c-4ed1-957b-0dcd906c2010
@samuel.stroschein @nils.jacobsen Okay folks we are mixing quite a few things here & have reached a scope way above Sherlock. Let me summarize this discussion, we need:
Parser
Lint Rule
App Specifc Functionality (Sherlock)
I would not advise for [3] upfront because why should somebody want go "backwards" the compilation step of the message function. This feels like the wrong DX/UX. Also, thinking about other libraries we need to support further: they also always start on the content/key side. See i18next.
So the mental model is always:
Let's have a short call after lunch :)
yep, time? 13:00?
Summary from the call:
@NilsJacobsen Can you create follow-up issues that we can close this discussion here?
Gonna talk to Loris about it and then add it to the right team.
I don't think encouraging devs to add extra variables to messages is a good idea as we are not able to consume all possible JS values. What if someone passes a user object instead of just the name? How do we detect the type of a value without reimplementing TS? This makes any "extraction" based approach (like a lint rule) undesirable.
Editing messages & making extra inputs available should be done in the same place that new messages are created. For devs that's Sherlock or files.
The question is, can we already lint if a user didn't add the required inputs?
The extra values would cause a type-error in the code. The dev already sees they're adding extra values & will just updated the message AST with the inputs.
Non-Devs wouldn't benefit from this lint rule since code with type-errors won't be committed.
I don't see a benefit to a lint rule.
The extra values would cause a type-error in the code.
This is already working right?
I don't see a benefit to a lint rule.
I don't think somebody is proposing that 😀
@felix.haeberle would it be possible to add a link/quickfix to the type error modal via Sherlock? How can these be adjusted?
@NilsJacobsen please follow the discussion we have in https://linear.app/opral/issue/SHERL-82/support-import-m-from-on-vscode-extension#comment-4082ba93 to learn about the CompletionItem
& CompletionProvider
.
See also: https://code.visualstudio.com/api/references/vscode-api#CompletionItemProvider
When developers add variables to a m-function they might think that this input declaration is also available in the ast (aka in the project for all other apps). But that is not the case.
Example
Developer knows that there is a count variable in the ref language so he adds the count variable right to the m function. At this point when I open fink, there is no count available as an input declariation in the ast. Im basically not able to use count as referencePattern or a selector unless I added the input again manually.
Proposal 1: Add a lint rule that is resolvable.
When I argument is passed into a m-function without a input declaration definition in the ast it get's linted. You can auto resolve the lint by adding it to the ast.
Proposal 2: Add a vs-code shortcut
Similar to the extract mechanism we could also add the input declaration in the ast and in the code with one step.
I fell like the lint rule would be the smoother solution, but I don't know how long we need to wait for it. This feature is needed at the time of message bundle component rollout, because this is such a basic use case.