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

refactor: remove jq dependency #35

Merged
merged 1 commit into from
Mar 13, 2024
Merged

refactor: remove jq dependency #35

merged 1 commit into from
Mar 13, 2024

Conversation

tcarac
Copy link

@tcarac tcarac commented Feb 24, 2024

  • Add Fallback strategy
  • Remove unnecessary registry
  • Remove Jquery dep
  • Upgrade node

@tcarac tcarac force-pushed the tcarac/cleanup branch 2 times, most recently from 49ddaee to 87c5717 Compare February 24, 2024 15:33
return pluginFn() || {};
}
export function hover(pluginFn, el) {
const isJqueryEl = el.jquery !== undefined;
Copy link
Member

Choose a reason for hiding this comment

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

Can we just leave it up to the the client code to add a new hover strategy with widget.strategies.add('hover', () => {}), if they want to have a jQuery hover option?

Copy link
Member

Choose a reason for hiding this comment

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

In fact I don't think this works, since #31 the hover strategy has been broken.

Notice that in UE we're using 1.3.0. We use 2.0.0 in another project and haven't used the hover strategy in that project yet.

Copy link
Author

Choose a reason for hiding this comment

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

Got it, still keeping the registry and opening it up to client registering new strategies makes sense.

el.addEventListener('mouseover', pluginFn, { once: true });
}
export function fallback(strategy, fallback) {
console.warn(`Strategy ${strategy} not found, falling back to ${fallback.name} strategy.`);
Copy link
Member

Choose a reason for hiding this comment

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

Maybe just throw InitiationNotSupportedError? This is a major mistake, it doesn't feel like a warning is sufficient.

Copy link
Author

Choose a reason for hiding this comment

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

So then not fallback at all.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, that's what I prefer anyway. I don't think throwing a "function undefined" method is helpful, but having a strict interface is good too.

Copy link
Member

@wheeyls wheeyls Feb 24, 2024

Choose a reason for hiding this comment

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

Actually I'm wrong, the fallback with warning is a good idea.

Moving a widget into a different environment probably shouldn't break it.

Copy link
Author

Choose a reason for hiding this comment

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

Actually I'm wrong, the fallback with warning is a good idea.

Moving a widget into a different environment probably shouldn't break it.

Yeah, that was my line too 👍

@wheeyls wheeyls merged commit 9b80ca9 into master Mar 13, 2024
1 check passed
@wheeyls wheeyls deleted the tcarac/cleanup branch March 13, 2024 14:30
@wheeyls
Copy link
Member

wheeyls commented Mar 13, 2024

Accidental merge here, going to revert.

The problem is that we are actively using the registry ourselves, we can't get rid of it.

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