Open XantreDev opened 1 year ago
Facing same issue
Lets write about it in nextjs repo
Yes. please comment the issue link. I will comment on it.
@wdcs-kushaltanna are you checked it in canary release of next?
Signals 1.3.1 repro https://stackblitz.com/edit/nextjs-e5kuk5?file=app/page.js
Any updates?
Seems related to https://github.com/remix-run/remix/issues/4164
seems the solution for now is to use signals-core
not signals-react
. That does not break the build on nextjs 13 using the app folder see : https://twitter.com/bersen0/status/1695908480392077466 and comments on https://github.com/vercel/next.js/issues/45054
I think in near future babel transform will solve this issue
@preact/signals, @preact/signals-react. @preact/signals-core, All of these libraries use client-side rendering. So, The App router won't be an approach to use such a feature. I suggest using the Page Router if anyone wants to use the Preact packages. Yes, you can convert the components into client components. But it'll just increase the codebase.
Steps to Verify:
npx create-next-app@latest
npm i @preact/signals-react
or yarn add @preact/signals-react
useSignal
hook outside of a component. If you want to declare a signal outside of a component, use the signal
function instead:
import { signal } from '@preact/signals-react';
export const welcomeText = signal('Awesome!');
4. **Must Do** Reload the website after implementation;
Proof of Work: https://github.com/malinjr07/preact-next
@preact/signals, @preact/signals-react. @preact/signals-core, All of these libraries use client-side rendering. So, The App router won't be an approach to use such a feature.
This is incorrect, you can use any RTS implementation to generate markup on a server. None of these packages are limited to browser environments.
As mentioned before, new babel transform (or other integrations I'm working on documenting) should increase ecosystem capability once we move away from monkey-patching React. Still working on the transform.
I think in near future babel transform will solve this issue
Do you think that Signals should then work with Next.js > 14 without any round trips?
I've tried to integrate the babel plugin with next. But had problems with some new next.js features, since it uses swc for bundling now. Probably for best integration we need to port the plugin for swc, too
The new 2.0.0 version of @preact/signals-react provides a useSignals()
hook that you can place in any component that reads a signal's value. It appears to work with Nextjs 14+ for me.
@JonAbrams , do you use it like this? Source: https://github.com/preactjs/signals/blob/d78f522411e6dec25c79b345bccb490c5fa57728/packages/react/README.md#usesignals-hook
Can you provide a minimal example, please?
I've implemented a plugin for SWC, will provide more info soon. It's working with next.js
I've implemented swc plugin how to use Here you can try it out: https://codesandbox.io/p/github/XantreGodlike/preact-signals-nextjs/main
@XantreDev I don't think it is compatible with latest Nextjs 14.2.1
@bacharSalleh I fixed it, it will be released soon (probably today). https://github.com/XantreDev/preact-signals/pull/99
I'm bumping this ticket.
Can the preact team please support SWC?
@XantreDev Could you make a pull request to this repository please? :)
No. I have more flexibility in my own repo. I want to iterate fast on issues and problems
Can the preact team please support SWC?
PRs are welcome and generally a better strategy than asking us to invest a dozen or so hours on your behalf.
If you really want to see a feature land, best way to do it is create a PR or fund someone to do the work.
I was under the impression that supporting Next.js was a goal for Preact Signals (since it also has a Babel plugin) and that @XantreDev forked to his own repo to make it happen.
@ss-twieland we have a limited amount of time throughout our day and this is something we do in our free time, if XantreDev does not want to contribute back that's his choice and we'll get to implementing our version in our own time 😅 if you however want to do it, we would encourage you to
@ss-twieland we have a limited amount of time throughout our day and this is something we do in our free time, if XantreDev does not want to contribute back that's his choice and we'll get to implementing our version in our own time 😅 if you however want to do it, we would encourage you to
I think I can invest my time in it, but I am not sure when. My version of SWC plugin will need some changes to work well with current signal store implementation
If you want to use signals with next.js now - you can today use @preact-signals/safe-react
with swc plugin
Just to emphasise, Preact is in no way affiliated with the @preact-signals
namespace and we are still a bit on the ropes about you using that namespace @XantreDev as you are trying to affiliate yourself with us without even communicating about it.
I was under the impression that supporting Next.js was a goal for Preact Signals
We have no explicit goals for supporting any framework as far as I am aware.
Next in particular is a bit of a challenge as it seems the React team is using it as a playground to test their ideas in (which causes a significant amount of instability), but if signals works there, we're happy to hear it! If not, support will require someone investing time (likely the community, I'm not sure if any of the core team uses Next at their day jobs) to make that happen.
Just to emphasise, Preact is in no way affiliated with the
@preact-signals
namespace and we are still a bit on the ropes about you using that namespace @XantreDev as you are trying to affiliate yourself with us without even communicating about it.
Sorry guys - I have no intenation to affiliate myself with preact/signals via the namespace. I wanted to create standard library for signals, but when signals didn't worked in HMR - it was painful to work with project. Andrew worked on Babel plugin more than half a year - so I though preact team have no resources to support react integration of signals. So I've copied babel plugin and simplified it. I think preact team are decent engineers, but at that point of time you was busy, so I though about providing support for react for signals by myself
Probably naming is confusing, maybe it could be named like @preact-signals-community/utils
Btw, I am open for communication
Just to be clear, I have no gripe with you making your own libraries at all. I do think that improvements as you are describing them are very welcome on our repository and I do my very best to review them and I know @rschristian does so as well. It's up to you to decide what path you take ofcourse, just wanted to throw all of this out there.
@XantreDev I gave your swc plugin a shot on a rather robust Next.js project. Unfortunately this swc plugin doesn't seem to work as intended. All I can really say is things were still sufficiently buggy in the application with your swc plugin and signal state was definitely not functioning as expected. Testing with the babel plugin things worked as expected so far as I could tell with general smoke-and-poke testing across the application. I'm not sure what the differences are between your plugin and the babel plugin other than yours is presumably a port of the babel plugin to swc. It's unfortunately not in my wheelhouse to work on an swc plugin but I'd consider that your example test case here is not nearly sufficient enough to consider your plugin a viable option that is stable for a production environment.
@XantreDev I gave your swc plugin a shot on a rather robust Next.js project. Unfortunately this swc plugin doesn't seem to work as intended. All I can really say is things were still sufficiently buggy in the application with your swc plugin and signal state was definitely not functioning as expected. Testing with the babel plugin things worked as expected so far as I could tell with general smoke-and-poke testing across the application. I'm not sure what the differences are between your plugin and the babel plugin other than yours is presumably a port of the babel plugin to swc. It's unfortunately not in my wheelhouse to work on an swc plugin but I'd consider that your example test case here is not nearly sufficient enough to consider your plugin a viable option that is stable for a production environment.
Can you provide more info about errors your encountered?
Preemptively, let's not debug a community plugin here. If anyone wants to work through issues w/ @XantreDev's plugin, please keep discussion to that repo. It's more beneficial to all users, those of our (Preact's) tools and Xantre's, if discussions about the tools are limited to the relevant repos.
We have to ask that discussions in this repo remain closely related to our tooling/libraries.
Thanks
Preemptively, let's not debug a community plugin here. If anyone wants to work through issues w/ @XantreDev's plugin, please keep discussion to that repo. It's more beneficial to all users, those of our (Preact's) tools and Xantre's, if discussions about the tools are limited to the relevant repos.
We have to ask that discussions in this repo remain closely related to our tooling/libraries.
Thanks
For sure—sorry. I’ll pick it up over there.