Keep 'DEV' in production-mode
I would like to make use of the $NAME-symbol from
solid-js/store
(for my experimentations at https://github.com/bigmistqke/solid-yjs-store, so i can allow multiple store-paths leading to the same reactive value). this is currently only exported as part of DEV afaik. Is there a way how to keep DEV available when doing a production-build?11 Replies
You cannot have dev in production, but you can build without production enabled. But that means that all the dev-only code (such as DEV object) gets included
It is probably development only for a reason 😛
The names themselves are only added during build, there is no use of them i prod
here is a pr wanting to expose the $NODE symbol in normal api, but it is stale for a while now
https://github.com/solidjs/solid/pull/1114
GitHub
export store symbol $NODE by LiQuidProQuo · Pull Request #1114 · so...
Summary
useful for more advance use cases.
make a prop readonly / prop guards
extend to support a property with get/set accessors
for example(requires patching, so wont work in playground)
http...
do this in your vite config if you want to deploy a dev build
mm ye, i think that would not be acceptable for a library to ask to its users. not that this project is going anywhere, but for the larp 🤣 i will bump your pr and ask for $NAME too.
what is the point of $NAME in prod? $NODE has some sense, but $NAME is only to give store nodes a name to display that in the DEVtools
also the $NAME will probably be deleted in the future
a really, i was imagining it to be a key to an object... didn't look into the actual implementation tbh
what do you need?
so i am playing around with a wrapper around setStore and bind it with yjs to create a store that is synced over multiple clients
to support for multiple store-paths leading to 1 signal
like when you shallow merge a reference to a store-node
and I thought $NAME could be the way how i could accomplish this.
but now that I am writing this, I think I don't need it actually
you know about this?
https://github.com/solidjs/solid/issues/1300
GitHub
Creating a store from another breaks read-write segregation · Issue...
Describe the bug You can easily create a store from a "read-only" proxy returned by another, gaining write access to the state and causing reactive updates to the original store. ...
ye i love that bug/feature and i use it a looooooot
super handy when dealing with situations where you have generated nested trees, instead of having to bookkeep these paths I do p.ex
const [child, setChild] = createStore(parent.some.nested.child)
the whole path-bookkeeping is a bit annoying w createStore tbh, but i still prefer it over mutable because of how explicit it is.another thing i don't really like w createMutable is that you have to think about the fact that you can only update values if you set a property, so you have to pass around the parent as well as the node you actually care about, which is kinda awkward. it's like giving you this mirage of a truly reactive variable in js, but then the friction is still too present. you don't have that with the
setChild
-pattern: https://playground.solidjs.com/anonymous/c4d78c36-5e35-4cba-bb3c-d67225d1b4c5Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
is a pretty sweet hack btw