feat(engine): support shorthand notation inside ~H sigil #278
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The full-module notation (`<MyMod.button>`) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because `.button` is not valid Elixir and ElixirSense was not able to make anything of it. This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to `<.button>` with `< button(assigns)` so that ElixirSense can correctly interpret it as a local function call with arity 1. This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included. While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.
The testing happens in Engine and there the presence of LiveView is mocked.
katafrakt
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #269
The full-module notation (
<MyMod.button>) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because.buttonis not valid Elixir and ElixirSense was not able to make anything of it.This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to
<.button>with< button(assigns)so that ElixirSense can correctly interpret it as a local function call with arity 1. This only happens whenphoenix_live_viewis added as a dependency1.This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included.
While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.
Footnotes
I looked into making a more detailed check here, basically checking if
Phoenix.Componentis imported into current module, but there's just too many ways to do so. I don't think the code analysis can do that, we would need to actually compile the code (using ElixirSense?). But I settled for a much simpler condition in this case. ↩