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

Finish splitting ViewSchema #166

Open
ecton opened this issue Feb 2, 2022 · 1 comment
Open

Finish splitting ViewSchema #166

ecton opened this issue Feb 2, 2022 · 1 comment
Labels
bug Something isn't working collections Issues impacting collections or views

Comments

@ecton
Copy link
Member

ecton commented Feb 2, 2022

I am trying to create a small app from scratch as part of doing a little last-minute testing on the alpha. I'm not going to hold up releasing the alpha for this, but I'm considering it a bug because I thought I had implemented it -- only I didn't quite get there.

The goal is the ability to have 3 crates define a project:

  • Shared: Any schema types that are needed to support the client. This should contain no backend code. Currently, ViewSchema must be defined in this crate.
  • Server: The backend related code, linking to the types in Shared. This is where ViewSchema should be defined.
  • Client: The client related code. It uses Shared for all types to be able to interact with the server.

ViewSchema is almost there, but the Schema process needs to be split into two to finish: one that only retrieves the Views, and one that retrieves the ViewSchemas. We need to figure out a way to make this as error-proof as possible.

@ecton ecton added bug Something isn't working collections Issues impacting collections or views labels Feb 2, 2022
@ecton ecton added this to To do in Khonsu Labs Roadmap via automation Feb 2, 2022
@ecton
Copy link
Member Author

ecton commented Feb 8, 2022

Last night I realized that version() needs to be moved back to View, or we need some mechanism for a network client to verify that the view type information is what they are expecting. The version number gives a hard-and-fast verification, but could also cause too many forced updates with server-only logic changes. Perhaps we should switch to SemVer as well to allow for more nuanced behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working collections Issues impacting collections or views
Projects
Status: Todo
Status: Todo
Development

No branches or pull requests

1 participant