wasm-demo quality of life improvements #81
Replies: 3 comments 5 replies
-
|
That's a lot of good ideas. I'm not a very proficient front-end developer, so if you can make a PR, I am more than happy to merge it. |
Beta Was this translation helpful? Give feedback.
-
|
Resolved by #93, except I didn't implement the Auto expand feature due to component limitations from BlueprintJS Some bigger ideas for future and other contributors:
|
Beta Was this translation helpful? Give feedback.
-
|
In the long term, some sort of web-based IDE is definitely needed. It could then either use the included WASM module or connect to a standalone server. For database IDEs, I personally like DataGrip the best and use it to manage all my postgres instances. The UI of DataGrip is orders of magnitude more complicated than the current demo, though, and I wonder if it's a better idea to start with something simpler. Some other thoughts about a potential IDE:
|
Beta Was this translation helpful? Give feedback.
-
|
The relational model is about generating code that efficiently performs First Order Logic inference over large amounts of data.
Most business logic can and should be expressed in First Order Logic and hence in the database.
ALSO much of UI generation logic can be represented in FOL.
The Cozo UI should be mostly written in Cozo.
I can discuss how to do this in more detail, but just imagine a query that returned a high-level description of what the UI should look like: a menu bar with these menu items, a tool pane with these items, a list pane and a detail or code pane. Imagine a query that starts from some assertions about what the user is engaged in, and returns a structure describing that UI. Totally doable in Cozo.
… On May 4, 2023, at 23:02, Ziyang Hu ***@***.***> wrote:
In the long term, some sort of web-based IDE is definitely needed. It could then either use the included WASM module or connect to a standalone server.
For database IDEs, I personally like DataGrip <https://www.jetbrains.com/datagrip/> the best and use it to manage all my postgres instances. The UI of DataGrip is orders of magnitude more complicated than the current demo, though, and I wonder if it's a better idea to start with something simpler.
Some other thoughts about a potential IDE:
Support table views (what we currently have) and graph views
Integration of LLMs, support "array programming" of running prompts on filtered data and store results into the same rows (basically one of the motivation for including the JSON type)
—
Reply to this email directly, view it on GitHub <#81 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAG7XZIS4NHJTX5GP3AKITXESJY3ANCNFSM6AAAAAAXQOWE3U>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
This is intriguing and something that I haven't thought about. At the moment it is unclear to me how to bridge the user's intention and UI. Does the user's intention manifest by clicking buttons, etc? Also, traditional UI is rigid, but rigidity has the benefit of assuring users that familiar functionalities can be found easily and always.give predictable results. How to prevent a UI written in logic be too fluid or fragile? |
Beta Was this translation helpful? Give feedback.
-
|
Software design has been so damaged by SQL for so long that I don't think we know how to best leverage FOL in software design. Some initial thoughts… A UI perhaps has a "focus", a value we are currently displaying (RESTish sort of thinking), and that value has one or more types. Those types provide the operations the user can perform on that type. Perhaps in the form of buttons and menu items, as well as maybe a Web Component that can display a value of this type when presented as JSON. So we are looking at a relation. The WebComponent is a table. The buttons do previous/next, sorting etc. Menu commands can go to the table definition and such. Or maybe we just have buttons for now. (I would love some built-in way to have a reference to a relation as a value; this is a second order logic so I get that this is complicated; for now, we can go through the host language to generate a new query containing the relation) The natural way to do forms is that they let the user provide values for non-ground variables. I don't think we can manipulate those in general, but we can present stored relation rows. The natural way to represent invoking a command is inserting into a relation having a host language trigger. We can use Cozo in the browser for client-side logic… I can understand if @zh217 didn't want to dive into this now. I'm planning to work on this myself, as part of my larger FREST project, so maybe wait until I've started working out some of these details. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think I can follow everything you've said now, but it sounds like a Haskell'ish thing where you let the type system write the program (draw the UI) for you. For such a system infinite relations are the norm rather than the exception, so we need ways either to prevent those, or by being lazy like in Haskell. Either way I think it is a great challenge. Would definitely love to understand more details when you have them worked out! |
Beta Was this translation helpful? Give feedback.
-
|
A new version of the WASM demo is now up, please check it out at https://www.cozodb.org/wasm-demo/ A notable addition is the ability to connect to a standalone server in addition to working with WASM. The source code is now separate from the main repo: https://github.com/cozodb/cozo-playground |
Beta Was this translation helpful? Give feedback.
-
Small improvements to the wasm-demo that can lead to better developer satisfaction:
These changes can be implemented in parallel with #65.
I should be able to bucket these improvements into a relatively small PR. let me know if you need a hand.
Beta Was this translation helpful? Give feedback.
All reactions