Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section schema and translation file completion and hover #298

Merged
merged 2 commits into from
Feb 27, 2024

Conversation

charlespwd
Copy link
Contributor

@charlespwd charlespwd commented Feb 19, 2024

What are you adding in this PR?

  • Add sections/*.liquid {% schema %} JSON schema intelligent code completion
  • Add sections/*.liquid {% schema %} JSON schema hover support
  • Add locales/*.json JSON schema intelligent code completion
  • Add locales/*.json JSON schema hover support

Fixes Shopify/develop-advanced-edits#140
Fixes Shopify/develop-advanced-edits#141
Fixes Shopify/develop-advanced-edits#142
Fixes Shopify/develop-advanced-edits#143
Fixes Shopify/develop-advanced-edits#147

schema.ICC.mp4

And some translation hover polish

polishing-translation-hover.mp4

Before you deploy

  • I included a minor bump changeset
  • My feature is backward compatible

yarn.lock Outdated Show resolved Hide resolved
@charlespwd charlespwd force-pushed the feature/section-schema-icc branch from 5f681bb to 32d21b9 Compare February 20, 2024 15:45
@charlespwd charlespwd marked this pull request as ready for review February 20, 2024 15:45
@charlespwd charlespwd force-pushed the feature/section-schema-icc branch from d19ccb5 to 465886b Compare February 21, 2024 14:51
@charlespwd charlespwd changed the title First pass Section Schema ICC + hover Add section schema and translation file completion and hover Feb 21, 2024
@charlespwd charlespwd force-pushed the feature/section-schema-icc branch 7 times, most recently from 4d4e30e to 4299f84 Compare February 23, 2024 14:49
): Promise<B> {
for (const loader of dataLoaders) {
try {
return transform(await loader());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This exists so that if either transform or the loader fails, we catch and try the next one.

This is to prevent having a loader that resolves to something that doesn't compile, or a loader to something that doesn't parse, etc.

It's to get a guarantee of something that works E2E.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome stuff! 🔥 I wonder if it would be a good idea to move this logic to the setup. Thus, if the outdated file is valid and the new one is unparseable, we could avoid memoizing the unparseable file. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmmmmm... I like the idea. We could do this at the downloadFile level with a validator instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make things a tad complicated. Because setup is stateful and assumes you're overriding a file (latest.json) and compares the results. If we wanted to do this, we'd need to integrate that transform/validity checker in download. It feels like that's going to be complicated.

The fallback should solve the problem of having an unparseable cached file.

case TranslationFileURI:
return this.jsonValidationSet.translationSchema();
default:
throw new Error(`No schema for ${uri}`);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This branch only happens if someone manually puts a "$schema" in their JSON objects. Which I don't believe we do have in themes.

Copy link
Contributor

@karreiro karreiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @charlespwd! Excellent/elegant stuff as always 🔥🔥🚀

I've only left some minor/non-blocking comments. The most significant one is about formatting. If you agree with that, we might handle it in a different PR :)

.github/workflows/ci.yml Show resolved Hide resolved
): Promise<B> {
for (const loader of dataLoaders) {
try {
return transform(await loader());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome stuff! 🔥 I wonder if it would be a good idea to move this logic to the setup. Thus, if the outdated file is valid and the new one is unparseable, we could avoid memoizing the unparseable file. What do you think?

Comment on lines +266 to +267
(await jsonLanguageService.completions(params)) ??
(await completionsProvider.completions(params))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I believe we could rely on AugmentedSourceCode (document) to route the language server implementation, thus the Liquid language server doesn't need to wait/depend on the JSON language server (which is probably blazingly fast).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm kind of hesitant here because JSON exists in Liquid files (in {% schema %} tags). So we kind of have to map between sections/*.liquid to the schema of section files from the JSONLanguageService.

Adding another layer of routing would result in a duplicated routing layer I think.

We could make those separate {completions,hover}/providers, but then we'd have to pass the service as a constructor argument and that, too, seems like unnecessary indirection.

@charlespwd charlespwd force-pushed the feature/section-schema-icc branch 2 times, most recently from 5e43859 to f42638c Compare February 27, 2024 13:04
@charlespwd charlespwd force-pushed the feature/section-schema-icc branch from f42638c to 976802c Compare February 27, 2024 13:04
@charlespwd charlespwd merged commit 042f1e0 into main Feb 27, 2024
5 checks passed
@charlespwd charlespwd deleted the feature/section-schema-icc branch October 2, 2024 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants