Your name has {len()} letters in it.
95 | ``` 96 | 97 | Why can't we? Because of *reactivity*. There's no way for the view to 'know' if `name` has changed. 98 | 99 | 100 | ## The reactivity problem 101 | 102 | UI frameworks are all, to some degree, examples of reactive programming. The notion is that your view can be thought of as a function of your state, and so when your state changes the view must, well... react. 103 | 104 | Reactivity is implemented in a variety of different ways (note: I am not expert in these frameworks other than Svelte, please correct any misapprehensions): 105 | 106 | * **React**'s approach is to re-render the world on every state change. This necessitates the use of a virtual DOM, which in turn necessitates a virtual DOM reconciler. It is effective, but an inefficient approach for three reasons: first, the developer's code must run frequently, providing ample opportunity for 'death by a thousand paper cuts' particularly if the developer is unskilled; second, the virtual DOM itself is a short-lived object, thirdly, discovering 'what changed' via virtual DOM diffing is wasteful in the common case that the answer is 'not much'. Reasonable people can (and do) disagree about whether these inefficiences are impactful on real apps (the answer is presumably 'it depends'), but it is well known that the most reliable way to make code faster is for it to do less work, and React does a lot of work. 107 | 108 | * **Vue** can track which values changed using getters and setters (accessors). In other words, your data forms the basis of a 'viewmodel', with accessors corresponding to the initial properties. Assigning to one of them — `vm.foo = 1` — schedules an update. This code is pleasant to write but is not without its downsides — it can result in unpredictable behaviour as values are passed around the app, and it encourages mutation. It also involves some minor computational and memory overhead, and some gotchas when setting as-yet-unknown properties (this will be fixed in Vue 3 with proxies, but presumably at the cost of IE support). 109 | 110 | * **Svelte** provides each component with a `set` method (and a corresponding `get` method) allowing the developer to make explicit state changes. (Those changes are fully synchronous, which is both good and bad — good because the mental model and resulting stack traces are simple, bad because it can result in layout thrashing, buggy lifecycles, and infinite loops that need to be guarded against.) This is verbose when mutating or copying objects, and puts valuable things like first-class TypeScript integration essentially out of reach. 111 | 112 | None of these are ideal. But [we're a compiler](https://mobile.twitter.com/Rich_Harris/status/1057290365395451905), which means we have tools in our toolbox that are unique to Svelte. What if we could solve reactivity *at the language level*? 113 | 114 | This proposal outlines a novel (as far as we're aware) solution, while bringing a number of significant benefits: 115 | 116 | * Easier-to-grok design 117 | * Less application code 118 | * Smaller bundles 119 | * Simpler, more robust lifecycles 120 | * A realistic path towards first-class TypeScript support 121 | * Well-defined contracts between components and their consumers 122 | * Opportunities to adopt ideas like [time slicing and Suspense](https://auth0.com/blog/time-slice-suspense-react16/) 123 | 124 | 125 | ## Detailed design 126 | 127 | Consider a counter component, the workhorse of examples such as these: 128 | 129 | ```html 130 | 133 | 134 | 137 | ``` 138 | 139 | > The quotes around the event handler are unnecessary as far as Svelte is concerned, but included for the sake of non-Svelte-aware syntax highlighting 140 | 141 | Here, we have declared a single state variable, `count`, with an initial value of `0`. The code inside the ` 163 | 164 | 167 | ``` 168 | 169 | ...would be transformed to something like this: 170 | 171 | ```js 172 | function create_main_fragment(component, ctx) { 173 | // ... the code that creates and maintains the view — 174 | // this will be relatively unaffected by this proposal 175 | } 176 | 177 | const Component = defineComponent((__update) => { 178 | let count = 0; 179 | const incr = () => { 180 | count += 1; 181 | __update({ count: true }); 182 | }; 183 | 184 | return [ 185 | // this creates the top-level `ctx` variable for `create_main_fragment` 186 | () => ({ count }) 187 | ]; 188 | }, create_main_fragment); 189 | ``` 190 | 191 | **This behaviour might seem surprising, even shocking at first.** Variable assignment does not have side-effects in JavaScript, meaning that this is arguably something else — [SvelteScript](https://mobile.twitter.com/youyuxi/status/1057291776724271104), perhaps. In practice though, developers readily embrace 'magic' that makes their day-to-day lives easier as long as the mechanisms are ultimately easy to understand — something observed with React Hooks, Vue's reactivity system, Immer's approach to immutable data, and countless other examples. This does underscore the need for this code transformation to be well-documented and explained, however. 192 | 193 | 194 | ### Mutating objects and arrays 195 | 196 | While it's good practice to use immutable data in components, Svelte should not force developers to do so. Assigning to a property of an object or array would have the same basic behaviour — `a.b = c` would trigger an update on `a`. It's possible that changes could be tracked at a more granular level (i.e. tracking `a.b` rather than `a`, so that `{a.d}
` is unaffected), but these are implementation details beyond the scope of this RFC. 197 | 198 | Calling array methods would *not* trigger updates on those arrays. 199 | 200 | > `x = x` can be used to 'force' an update on `x`, in the rare cases it is necessary 201 | 202 | 203 | ### Props 204 | 205 | Many frameworks (and also web components) have a conceptual distinction between 'props' (values passed *to* a component) and 'state' (values that are internal to the component). Svelte does not. This is a shortcoming. 206 | 207 | There is a solution to this problem, but brace yourself — this may feel a little weird at first: 208 | 209 | ```html 210 | 213 | 214 |The time is {format_time(time)}
274 | ``` 275 | 276 | The `onDestroy` callback is associated with the component instance because it is called during instantiation; no compiler magic is involved. Beyond that (if it is called outside instantiation, an error is thrown), there are no rules or restrictions as to when a lifecycle function is called. Reusability is therefore straightforward: 277 | 278 | ```js 279 | // helpers.js 280 | import { onDestroy } from 'svelte'; 281 | 282 | export function useInterval(fn, ms) { 283 | const interval = setInterval(fn, ms); 284 | onDestroy(() => clearInterval(interval)); 285 | fn(); 286 | } 287 | ``` 288 | 289 | ```html 290 | 296 | 297 |The time is {formatTime(time)}
298 | ``` 299 | 300 | > This might seem less ergonomic than React Hooks, whereby you can do `const time = useCustomHook()`. The payoff is that you don't need to run that code on every single state change, and it's easier to see which values in a component are subject to change, and *when* a specific value is changing. 301 | 302 | There are three other lifecycle functions required — `onMount` (similar to `oncreate` in Svelte v2), `beforeUpdate` (similar to `onstate`) and `afterUpdate` (similar to `onupdate`): 303 | 304 | ```html 305 | 329 | ``` 330 | 331 | > Note that the `changed`, `current` and `previous` arguments, present in Svelte 2, are absent from these callbacks — I believe they are now unnecessary. 332 | 333 | Currently, `onstate` and `onupdate` run before and after every state change. Because Svelte 2 doesn't differentiate between external props and internal state, this can easily result in confusing cyclicality: 334 | 335 | ```js 336 | 356 | ``` 357 | 358 | Under this proposal, `beforeUpdate` callbacks run only once per cycle. This makes infinite loops impossible: 359 | 360 | ```html 361 | 378 | ``` 379 | 380 | > Note that `previous_temperature`, if unused in the view, will not get the reactive treatment. 381 | 382 | Any `afterUpdate` callbacks would run after the view was updated, whether as a result of prop or state changes. Assignments in an `afterUpdate` callback would result in an immediate re-render (once all `afterUpdate` callbacks have run, instead of on the next frame) but would *not* cause the callback to run again. This would allow components to respond to layout changes, for example. 383 | 384 | 385 | --- 386 | 387 | The remainder of this section will address how existing Svelte concepts are affected by this RFC. Some things (CSS etc) are unmentioned because they are unaffected, though if items are missing please raise your voice. 388 | 389 | 390 | ### Directives 391 | 392 | In Svelte 2 there are six different kinds of directive: 393 | 394 | * `on:[event]` and `on:[event]=[callExpression]` 395 | * `use:[action]` and `use:[action]=[argument]` 396 | * `ref:[name]` 397 | * `in:[transition]`, `out:[transition]` and `transition:[transition]`, and `in:[transition]=[params]` etc 398 | * `bind:[name]` and `bind:remote=[local]` 399 | * `class:[name]` and `class:[name]=[expression]` 400 | 401 | Currently, directive values do not have curly braces as delimiters. This is an occasional source of confusion (and compiler complexity) that can be resolved by making directives more like attributes: 402 | 403 | ```html 404 | 405 |now you see me
656 | {/if} 657 |{thing}
705 | {/each} 706 | ``` 707 | 708 | `things` would be injected into the instance ` 782 | ``` 783 | 784 | That opportunity no longer exists in this RFC. Instead we need some other way to express the concept of 'all the properties that were passed into this component'. One suggestion is to use the `bind` directive on (🐃) the `the list is {listHeight}px tall:
837 | 838 |{bar}
886 | {/if} 887 | 888 | 900 | ``` 901 | 902 | In the example above, there is no real need to calculate `bar` since it is not rendered, but it happens anyway. 903 | 904 | [RFC 3](https://github.com/sveltejs/rfcs/pull/8) proposed a Svelte 3 friendly alternative to computed properties that is more flexible and involves less boilerplate. 905 | 906 | ### svelte-extras 907 | 908 | Most of the methods in [svelte-extras](https://github.com/sveltejs/svelte-extras) no longer make sense. The two that we do want to reimplement are `tween` and `spring`. 909 | 910 | Happily, these will no longer involve monkey-patching components: 911 | 912 | ```html 913 | 934 | 935 |