-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Use Preact? #4058
Comments
Why do you think it'll be slower? Just the overhead we're adding that we won't use? I initially thought we'd get a speed up for the DOM, but maybe DOM Chef is really speedy. |
Both start from pre-parsed JSX; One ends up with plain DOM nodes while the other needs to keep track of them and diff them once we ask to change data. Our "change of data" currently directly changes the data on the DOM element. Our only overhead in this case is that sometimes we call Again I don't think this is substantially slower, but I don't doubt that it is at least a little bit slower. |
I’m more concerned about the third downside since it requires some work + I still don’t know how to manage things like |
I'm a little bit doubtful it's worth the effort. So I'm -0 on this. |
I think it mostly depends on the code it requires. If it ends up making it longer and more complex, no. For the append/insertBefore I can write some helpers so it will still be as easy as |
If we are to query DOM elements that we created in JSX we already use, then we don't need select for them. I really see an upside to DOM diffing instead of |
I select them again so that I don’t have to keep track of the 2 instances of the same widget. Really this is the shortest way to keep them in sync, but obviously it’s really fragile. This is also the same feature that would benefit from changing state in a single place, instead of changing it in 3 places and then trying to update the UI accordingly, also via CSS (the open/closed eye icon is handled via CSS selector; spaghetti all the way) That would be replaced with this, in the main JSX, without having to add code to update it later since we only change “setting” once: {setting === 'default' ? <Eye/> : <EyeClosed/>}
That’s right, that part is unaffected though. This issue is about replacing dom-chef, not attempting to rewrite the whole extension as a SPA. Each JSX piece will be treated as its own interactive widget and injected as before into the DOM. |
Requires too much work. Never mind. If I could use it just on some features it’d good, but typescript makes that impossible. |
Spaghetti it is. Enjoy. 🍝 |
Would it make sense to drop dom-chef and just go straight to Preact?
Downsides:
.append(<SomeJSX/>)
Upsides:
@primer/components
directly, which could reduce the amount of JSX we carryWe can try converting features gradually to test the feasibility and see what changes it brings. First from the simplest feature, then from a feature that would actually benefit from using Preact.
This will likely conflict with our existing JSX types, so we might have to clutter the codebase with
ts-expect-error
or just add|| true
in thebuild:typescript
npm script 😅The text was updated successfully, but these errors were encountered: