They're both going to be 9 characters (base 32 or base 36), also It's a bit pedantic but base32 is more broadly supported, and part of the same standard as base64.
https://www.rfc-editor.org/rfc/rfc4648#section-6
Mostly to save the space... I'm also using the YYYYMMDDhhmmss value as an integer so converting it back is slightly easier to visualize... I had already written and implemented the logic before I'd considered Math.floor(now/1000).toString(32) which would only be 7 chars.
I'm using grate for database migrations and just wanting to capture versioning that matches the project(s)... the release version is tagged to the release number, but every merge/push into master gets deployed to a shared dev db.... I wanted to better track those deployments... I'm also now adding a link to the repo url for the commit that was deployed.
In the end, it's mostly for uniqueness, and the githash is probably more valuable than the timestamp, I just wanted it there.
The biggest down side is GPLv3... which won't work if someone wants to use it in a GPL+Commercial product downstream. I understand the desire to monetize this component library, but it definitely precludes it for a lot of backed project usage.
Not sure I could even suggest a good alternative depending on the desired usage/outcome.
That's cool... and I literally meant Redux as a state machine on the server, have considered doing this for shared state app, and then sending JSON diffs to the client via WS, then client events likewise bubble to server as a round trip.
This would be for a shared learning environment/simulation... though could probably work for a game where some level of lag is tolerable. Such as a shared board or card game, etc.
Cool, made an issue/suggestion to tweak holidays slighrly.
Could definitely see this as part of a larger application that included calendar management, or even a reduced app that worked in concert with a CalDAV service.
Interesting, but only part of a solution. Aside: what's up with that version number?
I've given a lot of thought to needs that this would fit, and I've mostly considered the use of Redux, or something closer to it. The other part of the issue is what to do with that data, this is where you will likely either be replicating state changes/diffs across something like websocket channels or you will wrap that into something like Apollo for GraphQL updates similarly.
In any case, this really feels like only a small part of what you might need for a solution, and really need to consider how this fits and if it really suits the needs of an application/solution whole.
I really like your work on this. The only things I would probably change, would be to make button interactions "do" more on-click. Also, I'd probably have the text/textarea etc have an "invalid-color" attribute that applies to the text/border when the component is invalid, or have some other target beyond wrapping the entire component itself.
I also tend to activate validation as part of onBlur and keep it through all change events from then onward, red while invalid to green when corrected. Haven't really played with the library much just looked through the components themselves. I just tend to pay extra attention to the form fields, date pickers and a few other areas that a lot of component libraries tend to miss.
Definitely appreciate all your work on this and it's very cool indeed... may play with it for a small yew project I've been thinking of.