Added special UUID string field that resolves #11

[AshenColors]

Using the special uuid_string type makes it refer to the mostlyDisabled computed property and only allows editing if there's no ID in the route. (I tried making it configurable by doing !this.$route.params.id && !this.config.dataDefinition.fields._id.disabled but accessing that field that way doesn't make vue happy and I don't yet know enough to know why.) The default schema is untouched, so this shouldn't affect anyone else for now.

This also sets the stage for special handling of the field for barcode integration features, from scanning intents to transforming input (for example, because of how QR codes encode values, a digit-only UUID representation is much more compact than its string equivalent, and making a proof of concept of this that works with any random keyboard scanner will be my next target.) Rebased onto PR #12 and everything tests out fine, should merge without conflicts. I readily admit I have very little idea what I'm doing, so unload all barrels and I'll do as directed to improve.

Potentially resolves #11.

[FoxUSA]

This also sets the stage for special handling of the field for barcode integration features, from scanning intents to transforming input (for example, because of how QR codes encode values, a digit-only UUID representation is much more compact than its string equivalent, and making a proof of concept of this that works with any random keyboard scanner will be my next target.)

Just FYI, I use QR codes in my install. I get a digits only UUID is better but only by a few characters.
StoreDown used to have a built in UPC scanner but it was too annoying to deal with.

[FoxUSA]

I think I need to know why. It doesn't seem to do anything you cannot already do.
Also if we do add this, the documentation needs to be updated so this cannot be merged as is.

[FoxUSA]

Why? the disabled property is already field specific. What does URL encoding it do?

[FoxUSA]

Why not just enable it? If you leave it blank it will generate one. If you specify it, that will be used. If there is a conflict, the working branch version #12 will display an error.

[AshenColors]

Thank you for taking the time to review the concept. I wanted to get your feedback before writing it up further since I didn't know if this would be the right approach.

This implementation is different because IDs are special: if it already exists for an entry, you don't want it to be modifiable (lest you create a duplicate), even if you normally designate your own for new items from pregen labels, like in my workflow. The simple solution would be to make the disabled property !this.item._id but this locks up the field after typing one character.

Checking the URL instead makes sure that we're only unlocking it on the new entry screen. When an existing item is loaded, the URL changes, and the field is disabled. In its final form, I would like it to respect the config's _id disabled property so existing users don't see changes without altering their schema. There may be an easier way to get the same effect, but I only started learning Vue when I made the repo, so there's quite a bit I don't know.

Just FYI, I use QR codes in my install. I get a digits only UUID is better but only by a few characters. StoreDown used to have a built in UPC scanner but it was too annoying to deal with.

This is admittedly not the highest priority thing, but it makes more of a difference than you'd think. The 36 characters of the string form take 5.5 bits each for 198 bits. Int-only encoding uses 3.33 bits per digit, making a 39-digit UUID 130 bits, or about a 34% reduction. The resulting QR code is a lot easier to scan from further away and at a severe angle. This is only relevant since I put a QR code on the inside of a roll of tape I keep losing, and this makes the difference in scannability.

Anything I do towards this should stay out of other people's workflow. The idea was to have a watch on a ref for the field for a valid 39-digit int UUID the way uuid.stringify() likes it and transform the value if one shows up. If StoreDown ever generates barcodes for items, this would make sure that it can accept the most compact format with any barcode scanner and not break anyone's workflow.

The ref is the reason I'm breaking it out into another field, since I'm not sure how to generate a valid watch otherwise, nor did I know how to make only _id take the computed property above. If you had a suggestion on a more sensible approach to take, I can start over and figure out a similar way to achieve the same only-editable-on-new-entry effect or confine it entirely to my copy.

[FoxUSA]

This implementation is different because IDs are special: if it already exists for an entry, you don't want it to be modifiable (lest you create a duplicate), even if you normally designate your own for new items from pregen labels, like in my workflow. The simple solution would be to make the disabled property !this.item._id but this locks up the field after typing one character.

That is how it functions today. Try it on the demo. It will not let you save if you modify the ID after the initial save. In #12 it will display the console error in a toast.

This is admittedly not the highest priority thing, but it makes more of a difference than you'd think. The 36 characters of the string form take 5.5 bits each for 198 bits.

You are assuming something that is not a requirement for StoreDown. IDs happen to be autogenerated as UUIDs but they are not always or required to be. Any arbitrary value can be accepted as an ID. Hence why that field is a string.

So if we do what you are asking we would need code to see the 130 bit and assume it is a UUID and all other values accept as is.
I don't thing a 34% reduction is worth having two ingest code paths.

If StoreDown ever generates barcodes

I doubt it. There are stubs for it today but dealing with printers is hell. So makes me happy to let the software that comes with my printer software do it.

Plus, my magical utopia is RFIDs or something like AirTags. Where you can throw things in a box and it automagically updates/creates them.

[FoxUSA]

Unless my contributions become a minority, I am probably going to run this project with things I will use or see valuable. No hard feelings if you disagree and want to fork off. I ran OpenNote for years basically out of the kindness of my heart. So I have to use it and this is something that conflicts with how I use StoreDown(I have non uuid ids I imported from a spreadsheet I used before I wrote StoreDown). Hopefully my reasons and motivations make sense and we can still be friends.

[AshenColors]

Zero hard feelings, don't worry. It's still an insanely useful tool and I'm grateful it's been made available in the first place.