Skip to content
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

Only keyword keys are supported #1

Open
tomconnors opened this issue Feb 22, 2015 · 1 comment
Open

Only keyword keys are supported #1

tomconnors opened this issue Feb 22, 2015 · 1 comment

Comments

@tomconnors
Copy link

Hi there, thanks for this library!
My application uses some string keys in its state map, which plato currently doesn't support. I started working on adding support for strings, but I figured it would be worth generalizing it further to support any type for a key, plus adding a couple features. Thought I'd run this by you before I get too deep into it:

The keys in local storage would be in this format:

{base-key}[{separator}{type-of-key}:{value-of-key}, ...]": value

So for this map: {:foo {"bar" {{:qux "baz"} ['a 'b 'c]}}}, a separator _, and the base key "base-key", we'd get something like this in local storage:

{ "base-key_kw:foo_str:bar_hm:{:qux "baz"}": "[a b c]" }

Tangentially related features:

  • ability to control depth of paths that go into Local Storage keys. So we could, for instance, choose a depth of 2 and have a map like {:foo {:bar {:baz 3}}} and end up with this in local storage:
{ "base-key_kw:foo_kw:bar": "{:baz 3}" }
  • ability to control whether to put vectors into local storage keys or just serialize the whole thing. Something like {:foo [1 2 3]} could be:
"base-key_kw:foo": "[1 2 3]"

or

"base-key_kw:foo": [],
"base-key_kw:foo_0": 1,
"base-key_kw:foo_1": 2,
"base-key_kw:foo_2": 3
@eneroth
Copy link
Owner

eneroth commented Mar 26, 2015

Sorry for the aeonic response time!

Thanks for the input! I didn't even considered supporting anything but keywords since that is all I use, but you're very correct in that this could be generalized. However, adding only support for strings would leave the same situation, except that it now supports two types rather than just one.

Perhaps there should be a way of encoding any type as key. Perhaps by allowing the user of the library to extend a protocol. Some reflection needs to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants