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

What's the MVP that's shippable to hex.pm #2

Open
methyl opened this issue Oct 1, 2020 · 1 comment
Open

What's the MVP that's shippable to hex.pm #2

methyl opened this issue Oct 1, 2020 · 1 comment

Comments

@methyl
Copy link
Contributor

methyl commented Oct 1, 2020

What do we need to support to be ready to publish it to wider audience?

@methyl methyl added this to the Ship MVP to hex.pm milestone Oct 1, 2020
@harmon25
Copy link

harmon25 commented Oct 4, 2020

Not so much what we need to support - but ideas that have come to mind since I have actually been poking around and have it running.

Formalized/stable server API

Still familiarizing myself with the macro stuff - will need to collaborate more on this for sure. #1

  • Iron out use cases where data is shared between live_data servers(users).
    • For example, a postgres table, being accessed via live_data. How does a row change get propagated to the other connected users viewing that table? Shared state/data between users #3
  • Testing
    • could possibly leverage similar mechanism for testing a raw channel - have not really looked into it
  • Built in persistence?
    • Would be interesting to expose an API/option that automatically persists state to an ets table or something, for things like view/session state that that do not belong in a DB, but could persist between page refreshes/disconnecting/reconnecting to the channel.
    • Another idea would be allowing the client to periodically persist state, and when re(connecting) they provide an initial state that is passed to the server when joining the channel (am currently using a similar idea to avoid a loading state, could be expanded upon by passing the clients suggested default state to the server.
    • This could also be used to persist a users live_data ID - generating once when first loading the app - and then storing that in localstorage or whatever for the next time they connect to the page - keeping the component UUIDs more stable between page loads.
  • erlang cluster capability
    • registering the processes via {:global, "name"} might be enough, this is a change I made - seems to work OK.

live-data/core npm package

  • typescript
  • error/connection handling

live-data/hooks npm package

  • typescript
  • error/connection handling (should just need to wrap logic exposed from core package)

Examples/Docs

Lots of documented examples both simple and more complex of how this can be used. Probably just react until interest in some other framework emerges.

  • Persistence Ecto
  • Persistence ets
  • Authentication/Authorization (socket and channel?)
  • Chat (complex)
  • Todo (complex)
  • Multistep Forms (complex)
  • Form validation (simple?)
  • Modals (simple)
  • Counter (simple)
  • Tabs (simple)
  • Other ideas??
  • Docs Once APIs are more stable.

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