You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This temporarily regresses data binding,
since the downcasting doesn't quite work
for downcasting into a trait object
when we stored the actual object instead
Will look into using MOPA (my own personal any)
Copy file name to clipboardExpand all lines: README.md
+33-13
Original file line number
Diff line number
Diff line change
@@ -14,26 +14,23 @@ Oh, and black hole's form from the collapse of a core of iron.. you know, the on
14
14
15
15
---
16
16
17
-
## How it works
17
+
Everything is experimental, half-baked, full of caveats, and subject to change. But some basic principles are beginning to emerge. With Quasar...
18
+
-**all your app and component state are statically typed in data structures of your choosing**
19
+
-**updating state in your application automatically updates views** (unless you update your state via interior mutability)
18
20
19
-
Everything is experimental, half-baked, full of caveats, and subject to change. But currently:
21
+
## How it works
20
22
21
23
-**Template engines** are swappable. There are [`examples`](https://github.com/anowell/quasar/tree/master/examples) using [mustache](https://crates.io/crates/mustache)(default) and [maud](https://crates.io/crates/maud). But replacing the template engine is just a matter of implementing the `Renderable` trait.
22
-
-**Components** are the combination of data with a template or other rendering process - really anything that implements `Renderable`. Quasar takes ownership of your components when binding them to the DOM and makes the data available to your event handlers via `data()` and `data_mut()` methods. In general, methods that mutate the component will result in re-rendering it (TBD: at the end of the event handler or at next tick). Note, component data is local to the component and not shareable outside your component.
24
+
-**Components** are the combination of data with a template or other rendering process - really anything that implements `Renderable`. Quasar takes ownership of your components when binding them to the DOM and makes the data available to your event handlers via `data()` and `data_mut()` methods. In general, methods that mutate the component will result in re-rendering it at the end of the event handler. Note, component data is local to the component and not shareable outside your component.
23
25
-**Views** are the result of one-way binding of a component to the DOM. You can also attach event listeners to views. Note, that currently rendering a view uses the destructive `innerHtml = ...` approach, which kills DOM state like input focus, so eventually some sort of DOM diffing/patching or virtual DOM solution will become pretty important.
24
-
-**State** or the shared app data is also available to event handlers. It is partitioned by a key (and by `TypeId`), and any attempt to read a shared data partition (calling `data(key)`) automatically registeres your view as an observer of that data partion (to-be implemented). Any attempt to write to an app data partition (calling `data_mut(key)`) will automatically add all observer views for that data partition to the re-render queue (TBD: processed at the end of the event handler or at the next tick).
25
-
26
-
A couple basic principles are beginning to emerge. With Quasar...
27
-
-**it should be impossible in safe Rust to update state in your application without also updating views.**
28
-
-**all your app and component state are statically typed in data structures of your choosing**
26
+
-**App Data** is shared state that is also available to event handlers. It is partitioned by a key (and by `TypeId`), and any attempt to read a shared data partition (calling `data(key)`) automatically registers your view as an observer of that data partion. Any attempt to write to an app data partition (calling `data_mut(key)`) will automatically add all observer views for that data partition to the re-render queue process at the end of the event handler.
29
27
30
28
A basic example might include an HTML file like this:
31
29
32
30
```html
33
31
<html>
34
32
<body>
35
-
<Reversername="Malcom Reynolds"></Reverser>
36
-
<Reversername="Shepherd Book"></Reverser>
33
+
<divid="counter"></div>
37
34
</body>
38
35
</html>
39
36
```
@@ -66,13 +63,36 @@ fn main() {
66
63
67
64
See the [`examples`](https://github.com/anowell/quasar/tree/master/examples) directory to get a sense of how it works today.
68
65
69
-
## What's next?
66
+
## Goals
70
67
71
-
I'm still working to better understand what works and what's missing in [webplatform](https://github.com/tcr/rust-webplatform).
72
-
Here are some overarching questions that are guiding this experimentation right now:
68
+
Quasar is still exploring some ideas and working to better understand what works and what's missing in [webplatform](https://github.com/tcr/rust-webplatform). Here are some overarching questions that are guiding this experimentation right now:
73
69
74
70
- Can Quasar achieve a level of abstractions that feel comparable to modern Javascript frameworks? (I believe some macros could allow it to rival the declarative syntax of some other frameworks.)
75
71
- What might it look like to have "isomorphic" rust, where the same rendering code can run both client and server side?
76
72
- How can I leverage the type system to achieve more flexible and/or more robust frontend development? (e.g. trait-based templating, leveraging immutable vs mutable access as a gate for identifying views that observer or mutate specific data.)
77
73
78
74
Admittedly Quasar is absent any perf goals at this time. Quasar also lacks a clear vision for why Quasar would be "better than X", so I'll probably ask myself "what problem is Quasar really solving?" multiple times throughout this experimentation.
75
+
76
+
## Building
77
+
78
+
You'll need emscripten setup and activated (see [brson's post](https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627)), and then to add a couple compilation targets:
79
+
80
+
```bash
81
+
rustup target add asmjs-unknown-emscripten
82
+
rustup target add wasm32-unknown-emscripten
83
+
```
84
+
85
+
Then `bin/build-asm` wraps cargo to simplify much of the build process
86
+
87
+
```bash
88
+
bin/build-asm # build quasar
89
+
bin/build-asm reverser # build quasar and the reverser example (output copied to `static/`)
90
+
bin/build-asm app # build quasar and examples/app (output copied to `exaples/app/static/`)
91
+
bin/build all # build everyting
92
+
```
93
+
94
+
For any of the built examples, you can serve the result with any simple server, e.g. with the official nginx docker image:
95
+
96
+
```bash
97
+
docker run --rm -it -v `pwd`/static:/usr/share/nginx/html -p 8081:80 nginx
0 commit comments