You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 17, 2024. It is now read-only.
When using createUniqueId and persisting and loading data, clashing ids might be generated. This can lead to corrupted/missing data and I would therefore consider this to be critical behavior. (all tested with client side solid only)
I replaced calls to nanoid with createUniqueId in my app under the impression that I would need one less dependency, because solid just brings it with its api.
I am not sure if this is intended behavior or a bug. But if it is intended it would probably make sense to write a warning into the docs and also go into a bit more detail on what its purpose actually is. In my opinion this can easily lead to deter people from an otherwise amazing library (solidjs). I am lucky we figured this out in an internal app, where this wasn't super critical. But if this would've been a customer project and we had lost data due to it (apart from backup strategies) I would probaly think twice before using solid again.
This is just hypothetical of course - I love solid and the work you folks are doing 😉❤️
Your Example Website or App
Steps to Reproduce the Bug or Issue
I am not quite sure what the best way to reproduce this would be, but as far as I can tell in our case we ran code that called createUniqueId and persisted the created data. Later on we restarted our computer and created another entry which was created with the same id, replacing the content inside the store we were using.
Expected behavior
As a user reading the docs I expected createUniqueId to be actually unique and not create clashing ids. It would also be nice to be able to control the length of the generated ids.
Describe the bug
When using
createUniqueIdand persisting and loading data, clashing ids might be generated. This can lead to corrupted/missing data and I would therefore consider this to be critical behavior. (all tested with client side solid only)I replaced calls to
nanoidwithcreateUniqueIdin my app under the impression that I would need one less dependency, because solid just brings it with its api.I am not sure if this is intended behavior or a bug. But if it is intended it would probably make sense to write a warning into the docs and also go into a bit more detail on what its purpose actually is. In my opinion this can easily lead to deter people from an otherwise amazing library (solidjs). I am lucky we figured this out in an internal app, where this wasn't super critical. But if this would've been a customer project and we had lost data due to it (apart from backup strategies) I would probaly think twice before using solid again.
This is just hypothetical of course - I love solid and the work you folks are doing 😉❤️
Your Example Website or App
Steps to Reproduce the Bug or Issue
I am not quite sure what the best way to reproduce this would be, but as far as I can tell in our case we ran code that called
createUniqueIdand persisted the created data. Later on we restarted our computer and created another entry which was created with the same id, replacing the content inside the store we were using.Expected behavior
As a user reading the docs I expected
createUniqueIdto be actually unique and not create clashing ids. It would also be nice to be able to control the length of the generated ids.Screenshots or Videos
No response
Platform
Additional context
No response