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 class based Component and PureComponent to improve compatibility with React #2928

Open
gaetan-puleo opened this issue Jun 6, 2024 · 6 comments
Labels
enhancement New feature or request.

Comments

@gaetan-puleo
Copy link

What is the feature you are proposing?

I tried to use https://magicui.design/ with https://www.framer.com/motion/, it was not possible to use because Component is not exported.

I don't know what it takes to make it possible.

I would like to use this effect from Magicui.

https://magicui.design/docs/components/animated-beam

@gaetan-puleo gaetan-puleo added the enhancement New feature or request. label Jun 6, 2024
@usualoma
Copy link
Member

usualoma commented Jun 7, 2024

Component class

In React, the Component class is currently a Legacy API.
https://react.dev/reference/react/Component

Can Hono support Component class?

Yes, it is technically possible.
The most basic feature can be implemented with small changes such as #2933. There is little or no increase in bundle size for users who do not use the Component class in this implementation.

Should we merge these?

At experimental level it can be implemented immediately as above, but more time needs to be spent on implementation to claim full support. I would prefer not to merge at the moment because the cost is too high for 'supporting a Legacy API'. I would consider it again if I could find a bigger motivation to merge.

@gaetan-puleo
Copy link
Author

gaetan-puleo commented Jun 7, 2024

Hi @usualoma I agree for the legacy part but some libraries need Component to be implemented. I am talking about Framer in my case.

Do we want Hono to support popular libraries, if yes, I would say we can merge it, if No then I would say Hono should be used only for simple use case.

@usualoma
Copy link
Member

usualoma commented Jun 7, 2024

Hi @gaetan-puleo
Thanks for creating the issue and commenting. We will consider it.

@usualoma
Copy link
Member

usualoma commented Jun 7, 2024

Hi @yusukebe

In terms of implementation feasibility, I think it could be done with an approach like #2933.

However, looking at the way "hono" and "honox" are currently used, I think that users who need "React" often use "React" directly, not "hono/jsx/dom".

I am wondering if it makes sense to support legacy APIs in "hono/jsx/dom".

I know there are users who have high expectations of "hono/jsx/dom" and I think it would be an interesting challenge to move forward with #2933, but I don't think the maintenance costs are small.

What are your views on this?

@yusukebe
Copy link
Member

yusukebe commented Jun 8, 2024

In my opinion, we don't have to support the legacy APIs in hono/jsx or hono/jsx/dom. As @usualoma said, if users want React, they can use React in their Hono application. The good point for Hono and HonoX is that users can use any UI library, not only hono/jsx.

Nevertheless, it is very interesting to see React libraries running in hono/jsx. It is not really possible to implement all of them, so for now, if we are going to draw a line, it is better not to implement the legacy APIs. We will need to think about new features for React 19 in the future.

@usualoma
Copy link
Member

usualoma commented Jun 8, 2024

@gaetan-puleo @yusukebe Thank you!

So, let's make it a policy not to add support for the Component class for now.

I'll leave #2933 (which I implemented a little extra after the first comment, so it's almost ready to work) as a POC. If the opinion changes in the future to support it, we'll use it then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request.
Projects
None yet
Development

No branches or pull requests

3 participants