-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Enable JSX support in frontend #15293
Conversation
010f29c
to
86d10de
Compare
4985302
to
27fb6a6
Compare
Switched to vhtml which is a more lightweight JSX rendering alternative that outputs strings instead of DOM elements which I think is more suitable to our general use cases. Escaping is still taken care automatically and we save around 8kB unminified bundle size with it compared to |
Some more refactors done. Moved the JSX components to its own file and added a informational comment about them. I've been attempting to test the components but could not get the JSX tranformation to work with the unstable version of Jest, so I guess we'll have to wait a bit for jest to stabilize their ESM features. |
I guess I may actually switch it back to |
Why not just continue with vue but switch to JSX ? |
Vue/React are for SPA-style rendering (e.g. build DOM elements and render/update). Only few isolated components in the UI use this type of renderning. This JSX usage is for cases where we only construct DOM elements/HTML and insert them manually ( |
Using Vue JSX later on should be possible, we just need to define multiple |
69c0e2f
to
7584dc7
Compare
Switched back to |
CI still failed. |
This enables frontend to use JSX to generate DOM nodes using the `jsx-dom` module [1]. JSX is inherently safer than concatenating HTML strings because it defaults to HTML escaping. Also it is easier to work with and more powerful than template strings. To demonstrate JSX usage, I've rewritten the context popup feature to use it, no functional changes there. [1]: https://github.com/proteriax/jsx-dom
Can't be related, rebased. |
I would also prefer that these components be converted to Vue instead of jsx, we already have way too big frankenstein in fronted to introduce yet another concept |
I'm not going to do Vue, sorry. I could easily convert all current string-built HTML to JSX but to me Vue is a framework I deeply disagree with and I'd rather like to get rid of it in favor of React. The JSX currently returns plain DOM elements but could easily be converted to React later. Maybe also migrate the existing Vue components to React. I think JSX is by far the best way of representing HTML in JS, there are no strange |
I will agree to disagree 😸 I'm on the other hand don't like react very much but everyone has their own favorites and I respect that 😉 |
Well if you really want to keep it to Vue, we could use the Vue JSX factory function, e.g. https://github.com/vuejs/jsx-next#content. It looks exactly like a React functional component in the simplest variant and close to it in the other variants, they Vue has apparently been copying hard from React on that part. I think using that JSX means current components need to migrate to Vue 3 because Vue 2 does not export the necessary factory functions. It'd be a mess which would probably have to load Vue twice.
I'd count that as a benefit of PHP. I enjoy being able to use JS functional methods like |
That's to be honest is exactly what I dislike about react most is mixing js with html 😕 |
The pure VUE is a framework like jquery, it's very small. I think the .vue file is better than js or JSX syntax because it's more clear to developers, it will not mix different type codes. I agree we should switch to vue3 but it's for better performance and smaller size. |
I still want to replace all the current places that construct HTML from strings with JSX, I don't really care whether it's Vue or something else that is processing the JSX as long as the output format of DOM nodes or string is possible. Vue 3 (finally) embraces JSX and I think it's the future, so I prefer if we start converting the existing SFCs to Vue 3 JSX. |
Not sure whether that supports all our current webpack use cases. Stuff like license file generation may not be possible. Webpack is certainly much more flexible in terms of extensibility. |
Do you dislike React or dislike JSX? I think it's a weak argument. Composing HTML parts from JS just feels natural to me and it's already practiced in many places in the current code base because it is essentially the only possible way. |
The same is true for https://bundlephobia.com/result?p=react@17.0.2 |
Is both an answer? :) But yeah I dislike JSX mostly because of mixed JS and HTML that makes it unbearably unreadable. And react for it's bulkiness and some of it's design decisions. I like vue that's just like go is plain and simple, maybe I'm too old but I'm too tired of complex languages that makes it hard to maintain in the end, I have seen too many such systems in last 20 years 😆 |
Only change here still needed is moving contrast color function to utils.js. @silverwind can you move it to other PR? |
Yes I can extract that later. |
I vote for Vue3 (Vue is already used in this project) + JSX (nice to have) |
Closing as this won't happen. |
I think it is good, if more people accept it, maybe we can welcome it back in future. |
Yeah, I'm still in favor of JSX for inline HTML snippets. We should at least have something that auto-escapes inserted values (but also provides a way to intentionally have unescaped content like SVGs). GitHub apparently uses https://github.com/lit/lit/tree/main/packages/lit-html for this, but I'm not sure it's suitable because I see no way to introduce unescaped content. Also, it seems to bloated in case one only uses the template function, we effectively get the same by using |
This enables frontend to use JSX to generate DOM nodes using the
jsx-dom
module. JSX is inherently safer than concatenating HTML strings because it defaults to HTML escaping. Also it is easier to work with and more powerful than template strings.To demonstrate JSX usage, I've rewritten the context popup feature to use it, looks pretty much exactly as before:
Generally the aim of this feature is to provide a safe and convenient alternative to string concatenation to generate DOM elements. I plan to migrate more string usage to this method after this is merged.