-
Notifications
You must be signed in to change notification settings - Fork 23
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
Handling multiple instances of a component with tweaks #36
Comments
While yes, to solve this you should hoist up the tweaks and then pass down the props or use context, it might be a common enough case that we would want to solve. Cc @dbismut what do you think? |
If we do this then we should use zustand as you initially thought @gsimone 😂 const { color } = useStore(s => ({ color: s.color })) I think it makes a lot of sense. EDIT: I think we would need to prevent unnecessary renders of components that don't subscribe to the whole state. Not sure zustand is the right one here, maybe jotai but that would mean having a provider... |
@Pocket-titan It's harder than I thought. It needs to keep track of all panes and nested panes added by components and remove them only when none is being used. I gave it a shot today on the zustand branch here https://github.com/pmndrs/use-tweaks/tree/zustand. I'm not proud of this: it is bug prone and really feels like we're fighting Tweakpane and React at the same time. |
I see! Now that you mention it, another difficulty comes to mind:
const { scale } = useTweaks("Suzanne", {
...makeFolder("Scale", {
scale: { value: 1, max: 3 },
}),
// Can't do this, only the button of the last instance rendered will show up (due to key equality things?)!
...makeButton(`Delete number ${id}`, () => {
remove();
})
});
// Have to add this "unique" tweak to its own folder to make it work
useTweaks(`Suzanne number ${id}`, {
...makeButton("Remove", () => {
remove();
}),
}) where At first I thought that maybe Here's an idea: what if we check for the (Tbf: this would still require the use of zustand, but maybe it would be easier b/c this way you don't have to deal with the nesting? but using |
Hi @Pocket-titan we got pumped and decided to rewrite something from scratch, that fits React and supports your idea out of the box with no major hassle. useTweaks({ color: 1, number: 4 }, folder("sub", { a: 2, b: 3 }, folder("sub2", { c: 4 }))) You'll also be able to do: useTweaks("sub.sub2", { c: 4 }) And get the value. Of course the value will only be initialized once (by the first hooks that gets called). We'll try to release something in alpha as soon as it's usable. PS: the idea is to store the data structure but flatten. So that the store looks like: {
"valueKey": value
"folder.subfolder.valueKey": value
// ...
} |
If anybody comes across this and wants to try alphas of the new version, drop me a DM on twitter or an email! |
@gsimone what ended up happening with this? |
@joeyfigaro They are currently working on another library leva. This repository was transferred from them to the official Tweakpane organization but there is no active maintainer at this time. I want to handle it but I'm busy updating the core... |
Hey! Love the library :)
I have multiple instances of a component with a
useTweaks
call, say:However, every single instance
Button
will add its owncolor
setting in the tweakpane, whereas my intent was to have them all share the same value.My question: should I just hoist the
useTweaks
call up one level and pass the tweaked value down as a prop (feels kind of meh)? Or is there a nicer solution to this? I tried passing the samepresetKey
but they still have different tweakpane inputs.Here's a sandbox demonstrating the "issue": https://codesandbox.io/s/gracious-bas-22vg2?file=/src/App.tsx.
The text was updated successfully, but these errors were encountered: