From a6f7f0d9ffad0c9fb863a8b743ab15879e245291 Mon Sep 17 00:00:00 2001 From: Michael Zhang Date: Wed, 12 Feb 2020 00:21:08 -0600 Subject: [PATCH] ouais --- content/enterprise/prototype/index.md | 51 +++++++++++++++++++++++++-- sass/_graph.scss | 15 ++++++++ sass/main.scss | 2 ++ 3 files changed, 66 insertions(+), 2 deletions(-) create mode 100644 sass/_graph.scss diff --git a/content/enterprise/prototype/index.md b/content/enterprise/prototype/index.md index 982fe38..b4011cc 100644 --- a/content/enterprise/prototype/index.md +++ b/content/enterprise/prototype/index.md @@ -8,13 +8,14 @@ template = "post.html" tags = [] +++ +NB: It's been a while since I wrote a post here. Since I began working at Epic, I've found it hard to motivate myself to even work on projects, let alone writing, after work hours. Hopefully I can pick it back up. + This past weekend, while on my trip to Minneapolis, I completed a very early prototype of "enterprise", a new UI framework I've been kind of envisioning over the past couple of weeks. While the UI framework is mainly targeted at web apps, the hope is that with a bit more effort, native UIs can be produced with almost no changes to existing applications. Before I begin to describe how it works, I'd like to acknowledge [Nathan Ringo][1] for his massively helpful feedback in both the ideation and the implementation process. ## Goals of the project -* **Complete separation of business logic from UI.** Theoretically, one could completely retarget the application to a completely different platform (mobile, web, native, something new that will pop up in 5 years), without changing any of the core logic. It does this by introducing [DSL][2]s that are completely architecture-independent. +* **Complete separation of business logic from UI.** Theoretically, one could completely retarget the application to a completely different platform (mobile, web, native, something new that will pop up in 5 years), without changing any of the core logic. It does this by introducing [declarative][4]-style [DSL][2]s that are completely architecture-independent. * **Maximally static component relationships.** Like [Svelte][3], I'm aiming to resolve as many relationships between elements as possible during compile-time, to avoid having to maintain a full virtual DOM at runtime. -* ## Prototype @@ -44,8 +45,54 @@ view { } ``` +This looks a lot closer to {React, Vue, Svelte, component structure}-ish code. The idea now is that the "compiler", as I've come to call it, reads the entire specification of the code and creates a sort of dependency graph of actions. For clarity, let's assign some IDs first: +* Let the `TextBox`'s value attribute be `view_value`. +* Let the `{name}` code segment in "Hello, name" be `view_name`. +* Let the model's name field be `model_name`. + +Now we can model this as: + +```dot +digraph "dependency graph" { + graph[bgcolor="transparent", class="default-coloring"]; + rankdir="LR"; + + "view_value" -> "model_name" + "model_name" -> "view_name" +} +``` + +The arrows in this graph indicate a dependency where changes to `view_value` propagates down the graph until everything else is changed. For the initial prototype, the data structure passed through this graph is simply a string, but with encoding magic and additional specifications, we can add rich text later. What this means the compiler then generates code that looks something like (but not exactly): + +```rs +fn create_view_value(model: &mut Model) -> INode { + let el = (...); + el.add_event_listener(|evt: InputListener| { + let new_value = el.get_attribute("value"); + model.name = new_value; + view_name.set_text(new_value); + }); + el +} +``` + +There's some complications involving the exact model representation in memory as well as how web attributes are accessed that makes the real code a bit different, but from this example you should be able to see that our "compiler" generated real code that matches our specification above. + +The full code for this can be found [here][5]. + +## Future + +Obviously not everyone's application is as simple as a linear dependency graph of simple string values. In fact, I even cheated a bit to get this prototype to function; here's some of the shortcuts I took: + +* I mostly hardcoded web elements in instead of making platform-independent abstractions. +* I hardcoded the actual specification for the app myself since the DSL doesn't have a real syntax yet. +* All data are string types. + +I'll be working on this some more in the coming weeks, so I'll try to keep updates posted here a bit more frequently. Until then, thanks for reading! [1]: https://remexre.xyz [2]: https://en.wikipedia.org/wiki/Domain-specific_language [3]: https://svelte.dev +[4]: https://en.wikipedia.org/wiki/Declarative_programming +[5]: https://git.iptq.io/michael/enterprise diff --git a/sass/_graph.scss b/sass/_graph.scss new file mode 100644 index 0000000..b088d52 --- /dev/null +++ b/sass/_graph.scss @@ -0,0 +1,15 @@ +.graphviz { + .graph.default-coloring { + ellipse, path, polygon { + stroke: $text-color; + } + + text { + fill: $text-color; + } + + * { + font-family: $sansfont; + } + } +} diff --git a/sass/main.scss b/sass/main.scss index e7aa9aa..fc342c9 100644 --- a/sass/main.scss +++ b/sass/main.scss @@ -11,6 +11,7 @@ $monofont: "Roboto Mono", "Roboto Mono for Powerline", "Inconsolata", "Consolas" $small-text-color: lighten($text-color, 10%); $link-color: royalblue; @import "content"; + @import "graph"; } @media (prefers-color-scheme: dark) { @@ -19,4 +20,5 @@ $monofont: "Roboto Mono", "Roboto Mono for Powerline", "Inconsolata", "Consolas" $small-text-color: darken($text-color, 10%); $link-color: lightskyblue; @import "content"; + @import "graph"; }