Responsive Svelte (exploring Svelte's reactivity)
Tags: svelte, reactivity, webdev, javascript
Published: 2020-07-17 16:49:03

---
title: Responsive Svelte (exploring Svelte's reactivity)
published: true
description: exploring Svelte's reactivity
tags: svelte,reactivity,webdev,javascript
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/abbgyq2bwzeczr5mzq59.png
---

<!--- AI: PUBLISH to dev.to: comment out next two ... handled (above)
![Responsive Svelte](https://dev-to-uploads.s3.amazonaws.com/i/abbgyq2bwzeczr5mzq59.png)
# Responsive Svelte (exploring Svelte's reactivity)
 ---> 

[Svelte] is truly a new and revolutionary approach to web development!  It does an amazing job of automating your app's reactivity.

This article is focused on uncovering some **"behind the scene"** detail of **Svelte's reactivity**.  We will do this from an "observer perspective" - _by visualizing Svelte's reactivity first-hand **(right in our application)**_!  There's a bit of a mystery behind some of these concepts.  We will **delve into some lesser-known detail** _(that you may have not considered)_!  The hope is you will come away with more insight, and be better informed on how to use this awesome product!

This is **not a Svelte tutorial**.  For the most part, any developer should be able to comprehend the concepts discussed here.  Ideally you should know the basics of Svelte.  While you won't need to be an expert, we will **not** spend time explaining rudimentary Svelte constructs.

**A big thanks** to [Mark Volkmann] for his review of my effort.  I am just starting my Svelte journey, so Mark's insight was invaluable!  You may want to check out his new book: [Svelte and Sapper in Action](https://www.manning.com/books/svelte-and-sapper-in-action).


<!---*** Section ***************************************************************---> 
## At a Glance

<!--- SHORTCOMING: dev.to: TOC does NOT indent on 3rd level ... limit to two :-( ---> 

- [TL;DR]
- [Video Presentation]
- [Svelte Reactivity]
- [Reactive Triggers]
  - [Primitive Types]
  - [Object Types]
  - [Staleness Summary]
- [Exploring App Reactivity]
  - [Diagnostic Logging Probes]
  - [Advanced Diagnostics]
- [Demo App]
- [Inspecting App Reactivity]
  - [Logging Probes]
  - [Advanced Probes]
- [Re-Render Analysis]
  - [Dereferencing Objects]
  - [Svelte's Re-Render Optimization]
  - [Svelte Compiler Output]
  - [Svelte's Reflexivity is Very Efficient]
- [App Reactivity Tweaks]
  - [Finer Grained Dependency Management]
  - [Preresolve Variations]
  - [Optimization Caveats]
- [Extra Credit Exercise]
- [Who is this guy?]
- [Summary]


<!---*** Section ***************************************************************---> 
## TL;DR

As a general rule, I would recommend reading the article in it's entirety.  With that said, if you wish to **"cut to the chase"**, I have summarized my findings at the end ... feel free to jump ahead to the [Summary]!


<!---*** Section ***************************************************************---> 
## Video Presentation

_If you are visually inclined_, **I gave the following presentation** to [Svelte Summit](https://sveltesummit.com/) in the fall of 2021:

<!--- AI: PUBLISH to dev.to: use the special syntax:  ---> 
{% youtube fvY1TAKNPgY %}

[Full Syllabus & Resource Links](https://bit.ly/r-svelte)


<!---*** Section ***************************************************************---> 
## Svelte Reactivity

Being new to Svelte, I am absolutely fascinated with the fact that **"reactivity is simply baked right into my app"**!  _This is sooooo kooool_!

In frameworks like React, your app must trigger reactivity _(with things like `setState()`)_, and the big focal point is: **"When does my component re-render"**?

With Svelte, reactivity happens automatically, and it is much finer grained than the component level.  In Svelte, **individual snippets of any component may dynamically re-generate at any time**!

Svelte meticulously manages each snippet, monitoring and re-executing them as needed, based on changes in their dependent state.  Herein lies the beauty of Svelte: it accomplishes all of this automatically through it's compiler philosophy ... converting our declarative component-based code into JavaScript that incrementally manipulates the DOM directly!  Svelte both eliminates boilerplate code, and is truly reactive out-of-the-box, without employing a bloated in-memory run-time framework.  **How kool is that?**

So **what** _(you may be asking)_ **is a snippet**?  _This is actually **my term**_. For the purposes of this article, the term **"snippet"** refers to any JavaScript expression that Svelte reactively manages and re-executes at the appropriate time _(i.e. whenever dependent state changes)_.  Ultimately, snippets are used in providing the dynamics of our html markup _(i.e. it's reactivity)_.

**Snippets may be found in two places**:

<!--- AI: PUBLISH to dev.to: bullets with blank lines ... 1. PREFIX subsequent group with TAB   2. BLANK LINES prefixed with "TAB &nbsp;" (EXCEPT AROUND CODE-SNIPPETS - BUT THEM RIGHT UP) ---> 

1. **code-snippets**:
	**code-snippets** are found in the component's JavaScript code _(within the `<script>` tag)_, and demarked with Svelte's `$:` label.  This is referred to as **Reactive Declarations** and **Reactive Statements**.
	```js
	$: {name, phone} = user;
	```
	Generally speaking, **code-snippets** are typically lightweight, in that they result in changes to JavaScript state variables.  With that said, however, the sole reason for these state changes is to be referenced in our html markup _(either directly or indirectly)_.
	
	In the sample above, the snippet will re-execute whenever the `user` object changes _(the snippet's dependency)_, re-assigning the `name` and `phone` variables.
2. **html-snippets**:
	**html-snippets** are found in the component's html markup, delineated through curly braces: `{...}`.  This is commonly referred to as _**interpolation**_.
	```html
	<p>Hello {name}</p>
	<p>May we call you at {phone}</p>
	```
	**html-snippets** are typically more heavyweight, in that **they result in changes to the html DOM**!  _But hey ... that is the whole reason we are here_ ... i.e. **the crux of our reactivity**!
	
	In the sample above, the first snippet will re-generate it's html when `name` changes, and the second when `phone` changes.


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Terminology</mark>: snippet, code-snippet, and html-snippet

> Within this article, the term **snippet** refers to any JavaScript expression that Svelte reactively manages and invokes when it's dependent state changes.
>
> Snippets may either be:
> - **code-snippets** _(referred to as **Reactive Declarations** and **Reactive Statements**)_ 
> - or **html-snippets** _(commonly referred to as **interpolation**)_.  
>
> Ultimately, snippets provide the dynamics within our html markup _(i.e. it's reactivity)_.


<!---*** Sub-Section ***************************************************************---> 
## Reactive Triggers

So drilling into this topic just a bit more, you may be asking: **How does Svelte determine when to trigger the re-execution our snippets?**

The short answer is that Svelte monitors the dependent state referenced in each snippet, and triggers a re-execution whenever that state changes.

The followup question is: **How does Svelte determine that state references have changed?**

The Svelte docs talk about **"Assignments are 'reactive'"** and **"Svelte's reactivity is triggered by assignment"**.  What they are saying is that Svelte triggers reactivity through assignment semantics _(recognizing assignment in it's various forms)_.

This is true for the local state of a component.  The Svelte compiler will recognize assignment _(in it's various forms)_, and mark the assigned variable as changed _(i.e. "stale")_.

However, I have discovered that there is a **big distinction in whether the assignment target is a primitive or an object** _(including arrays)_.



<!---*** Sub-Sub-Section ***************************************************************---> 
### Primitive Types

For primitive types _(strings, numbers, booleans, etc.)_, reactivity only occurs when the value has changed.  In other words, it also incorporates JavaScript identity semantics (i.e. `priorState === nextState`).

So `myNum = (x + y) / 2` will only be marked as "stale" when it's value actually changes.  If the prior value was 10 and the calculation resulted in 10, then no reactivity will occur.

This is most certainly what one would expect, and I suppose it is rather obvious.  However the Svelte docs do not mention this _(as far as I can tell)_.  The only reason I dwell on this point is that it is in stark contrast to object-based reactivity.


<!---*** Sub-Sub-Section ***************************************************************---> 
### Object Types

Most applications require more complex state, typically modeled in objects _(or arrays)_.

As it turns out, in Svelte, any technique by which you change an object, will mark the entire object as "stale".  This includes local component objects, Svelte object stores, component object properties, etc.  This is also true when you mutate an object, and inform Svelte that the object has changed _(by assigning it to itself)_.

This means that the granularity of change that is being tracked is much broader in scope.  In other words, the entire object will be considered "stale" even though only one property may have changed.

<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Insight</mark>: Reactivity is based on change in dependent state

> Snippet execution is triggered when dependent state changes
>
> - primitive types trigger reactivity only when the value changes _(based on identity semantics)_
>
> - objects trigger reactivity per the entire object, not individual content


<!---*** Sub-Sub-Section ***************************************************************---> 
### Staleness Summary

The following table highlights what Svelte will consider "stale":

```
Given:
   let prim  = 1945; // a primitive
   let myObj = {     // an object
     foo: 1945,
     bar: 1945,
   };

Operation                      Marks this as "stale"
=============================  ======================================
prim++                         prim
prim = 1945                    prim (ONLY if prior value is NOT 1945)
                               
myObj.foo++                    myObj (all content of myObj)
myObj = {...myObj, foo:1945}   myObj (all content of myObj)
myObj.foo = 1945               myObj (all content of myObj)
myObj = myObj                  myObj (all content of myObj)
incrementFooIndirectly(myObj)  NOTHING
```

You can see a demo of this in my [Reactive Triggers REPL].  This visualizes reflexive counts _(highlighted in yellow)_, from the various operations _(listed above)_.  In order to fully understand how this REPL works, you need to know what a `ReflectiveCounter` is _(a new tool for your tool belt)_.  This is discussed in the [Advanced Diagnostics] section.  You may want to come back to this REPL after reading the next section.


<!---*** Section ***************************************************************---> 
## Exploring App Reactivity

Being the curious fellow that I am, I want to see my app's reactivity.  After all, I am originally from Missouri - _**the "Show-Me" State**_!

You might be saying: _"of course you can see the reactive results of your production app, through the state it is visualizing"_!

**BUT NO** ... that is NOT what I am talking about.  I want to definitively determine when Svelte triggers the execution of my snippets!  In other words, **I want to see Svelte's reactivity in action**!

In so doing, this will:

- help ground me in the Svelte philosophy

- give me insight on various Svelte heuristics _(dependency monitoring, reactive triggers, DOM updates, etc.)_

- give me a better appreciation for **"all this reactivity that is occurring (automatically) all around me"**

- and _we may just discover some detail that we hadn't considered_!

Of course, this is something that would be confined to a category of "diagnostic probes", and not part of our production app.

At first glance, this seems like a "difficult task", because Svelte is in control of this _(not us)_.  And **Svelte Devtools** doesn't provide any insight on this either _(it's focus is on reviewing state at a given point-in-time)_.


<!---*** Sub-Section ***************************************************************---> 
## Diagnostic Logging Probes

As it turn out, we can use a common "developer trick" to **logically-OR a console.log() prefix** to each of our snippets.

Consider this:

**Original:**
```html
<p>Hello {name}</p>
<p>May we call you at {phone}</p>
```

**With Logging Probes:**
```html
<p>Hello {console.log('Name section fired) || name}</p>
<p>May we call you at {console.log('Phone section fired) || phone}</p>
```

We have now prefixed each production expression with a `console.log()` that is logically-ORed.  Because `console.log()` returns nothing _(i.e. `undefined` which is falsy)_, the subsequent expression will unconditionally execute (resulting in the original html output).

In other words, this will generate the same html _(as our original production code)_, but with the **addition of diagnostic logs that are _emitted only when the snippet is executed_.**

As an example, say our `phone` state changes ... we will see the following emitted in our logs:

**logs:**
```
Phone section fired
```

You can see a **live demo** of this in the [Logging Probes] discussion.

It is **important to use unique texts in each probe**, so as to be able to correlate each log entry to it's corresponding snippet.

With the addition of these diagnostic probes, **our logs will definitively reveal when Svelte re-executes each snippet ... very kool indeed!**


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Takeaway</mark>: Monitor Svelte snippet invocations through logically-ORed prefixed expressions

> You can detect when Svelte executes a snippet by prefixing it with a **logically-ORed** monitor.
> 
> This can be a simple [logging probe] or a more advanced [ReflectiveCounter]



<!---*** Sub-Section ***************************************************************---> 
## Advanced Diagnostics

For most applications, these simple diagnostic logging probes will provide adequate insight into your app's reflexiveness.

However, depending on how many probes you need, it may become tedious to correlate these logs to the various sections.

In these cases we can replace the logs with a simple monitor, that **exposes a reflective-count for each section, _displayed directly on our page_**!

Here is the utility:

**createReflectiveCounters.js**
```js
export default function createReflectiveCounter(logMsg) {
  // our base writable store
  // ... -1 accounts for our initial monitor reflection (bumping it to 0)
  const {subscribe, set, update} = writable(-1);

  // expose our newly created custom store
  return {
    subscribe,
    monitor(...monitorDependents) {
      update((count) => count + 1);  // increment our count
      logMsg && console.log(logMsg); // optionally log (when msg supplied)
      return ''; // prevent rendering `undefined` on page (when used in isolation)
                 // ... still `falsy` when logically-ORed
    },
    reset: () => set(0)
  };
}
```

This creates a `ReflectiveCounter` (a custom store), suitable to be used in monitoring Svelte reflective counts.

In it's rudimentary form, a `ReflectiveCounter` is just a simple counter, however it's API is tailored to be used as a reflective monitor.

The `monitor()` method should be prefixed in a "Svelte invoked" snippet (either through a **logically-ORed** expression, or a **JS comma operator**).  It maintains a count of how often Svelte executes this snippet.

> **Example**: `<i>{fooSectionReflexiveCount.monitor() || $foo}</i>`

In turn these counts can be summarized directly on your page!

> **Example**: `<mark>{$fooSectionReflexiveCount}:</mark>`

The `monitor()` method may also be optionally supplied a set of `monitorDependent` parameters.  This is used when the dependents you wish to monitor are NOT already part of the production snippet.  Technically the utility does **not** use these parameters, rather it merely informs Svelte to monitor these dependents as criteria for re-invoking the snippet.  The following example monitors how many times a Svelte store has changed:

> **Example**: `$: fooStateChangeCount.monitor($foo);`

You may also optionally console log a message, _whenever the monitor() is executed_, by supplying a `logMsg` to the creator:

> **Example**: `const fooSectionReflexiveCount = createReflectiveCounter('Foo section fired');`

The `reset()` method can be used to reset the given count.

**USAGE:**

There are two distinct ways that `ReflectiveCounter` can be used:

<!--- AI: PUBLISH to dev.to: bullets with blank lines ... 1. PREFIX subsequent group with TAB   2. BLANK LINES prefixed with "TAB &nbsp;" (EXCEPT AROUND CODE SNIPPETS - BUT THEM RIGHT UP) ---> 

1. Monitor html reflexive counts (in html-snippets):
	```html
	<script>
	  const fooReflexiveCount = createReflectiveCounter('foo section fired');
	</script>
	
	<!-- diagnostic reporter -->
	<mark>{$fooReflexiveCount}:</mark>
	
	<!-- monitor this section -->
	<i>{fooReflexiveCount.monitor() || $foo}</i>
	
	<!-- reset counts -->
	<button on:click={fooReflexiveCount.reset}>Reset</button>
	```
2. Monitor state change counts (in code-snippets):
	```html
	<script>
	  const fooChangeCount = createReflectiveCounter();
	  $: fooChangeCount.monitor($foo);
	</script>
	
	<!-- reporter/resetter -->
	<i>$foo state change counts: {$fooChangeCount}</i>
	<button on:click={fooChangeCount.reset}>Reset</button>
	```

You can see a **live demo** of `ReflectiveCounters` in the [Advanced Probes] discussion.

<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Insight</mark>: Diagnostic probes are temporary

> Diagnostic probes should be considered temporary, and removed _(or commented out)_ when your analysis is complete.
>
> There are techniques where they can be disabled at run-time _(with minimal overhead)_, but this exercise is left up to the reader.



<!---*** Section ***************************************************************---> 
## Demo App

Before we can begin any analysis, we will need some code to play with.  It should be simple and focused, so we can concentrate on it's reactivity.

I have created an interactive demo (a Svelte REPL) that we can use.

<!--- SCREEN PRINT: GreetUser_operationA.png - shows demo basic operation  ---> 
**[Demo REPL]**:
<p align="center"><img width="50%" alt="Greet User Operation" src="https://dev-to-uploads.s3.amazonaws.com/i/rih5xpcbip28xdleteeq.png"></p>

The basic idea behind the demo is you can **maintain the characteristics of a logged-in user** _(the top-half: `EditUser.svelte`)_, and **display them** _(the bottom half: `GreetUser.svelte`)_ ... pretty simple :-) You can update one or more properties of the user by simply changing the text, and clicking the `Apply Change` button.  _**Go ahead and play with the interactive demo now**_!

The demo is broken up into a number of modules. I won't detail them here ... they are summarized in `App.svelte` (of the [Demo REPL]).

**SideBar**: Normally the `EditUser`/`GreetUser` components would be mutually exclusive _(i.e. displayed at different times)_ ... I merely **combined them** so we can **better see the "reflexive correlation" between the two**.

For our discussions, we will be focusing on a single module: the `GreetUser` component.

**GreetUser.svelte** _(see `GU1_original.svelte` in [Demo REPL])_
```html
<script>
 import user from './user.js';
</script>

<hr/>
<p><b>Greet User <mark><i>(original)</i></mark></b></p>

<p>Hello {$user.name}!</p>
<p>
  May we call you at:
  <i class:long-distance={$user.phone.startsWith('1-')}>
    {$user.phone}
  </i>?
</p>

<style>
 .long-distance {
   background-color: pink;
 }
</style>
```

This component merely greets the logged-in user _(an object-based Svelte store)_, visualizing individual properties of the user.  Long distance phone numbers will be highlighted _(when they begin with "1-")_.

**What could be simpler than this?** This should provide a good basis for our discussions :-)

    


<!---*** Section ***************************************************************---> 
## Inspecting App Reactivity

Let's enhance the `GreetUser` component with our **Diagnostic Probes** _(discussed in [Exploring App Reactivity])_ to see how well it behaves.


<!---*** Sub-Section ***************************************************************---> 
### Logging Probes

Here is our `GreetUser` component with the [Diagnostic Logging Probes] applied:

<!--- a code version with reflexive diagnostic logs ---> 
**GreetUser.svelte** _(see `GU2_logDiag.svelte` in [Demo REPL])_
```html
<script>
 import user from './user.js';

 // diagnostic probes monitoring reflection
 const probe1 = () => console.log('Name  section fired');
 const probe2 = () => console.log('Phone class   fired');
 const probe3 = () => console.log('Phone section fired');
</script>

<hr/>
<p><b>Greet User <mark><i>(with reflexive diagnostic logs)</i></mark></b></p>

<p>Hello {probe1() || $user.name}!</p>
<p>
  May we call you at:
  <i class:long-distance={probe2() || $user.phone.startsWith('1-')}>
    {probe3() || $user.phone}
  </i>?
</p>

<style>
 .long-distance {
   background-color: pink;
 }
</style>
```

You can run this version of the [Demo REPL] by selecting: <mark>with reflexive diagnostic logs</mark>.

<!--- SCREEN PRINT: GreetUser_logsA.png - show logging probe (selecting 'with reflexive diagnostic logs') ---> 
<p align="center"><img width="50%" alt="Logs show snippet execution!" src="https://dev-to-uploads.s3.amazonaws.com/i/vur99iu5vmokq5vaiknl.png"></p>

**Very nice** ... by analyzing the logs, we can determine exactly when individual html-snippets are re-executed!


<!---*** Sub-Section ***************************************************************---> 
### Advanced Probes

Let's also apply the [Advanced Diagnostics] _(just for fun)_, to see what they look like:

<!--- a code version with advanced on-screen diagnostics ---> 
**GreetUser.svelte** _(see `GU3_advancedDiag.svelte` in [Demo REPL])_
```html
<script>
 import user from './user.js';
 import createReflectiveCounter from './createReflectiveCounter.js';

 // diagnostic probes monitoring reflection
 const probe1 = createReflectiveCounter('Name  section fired');
 const probe2 = createReflectiveCounter('Phone class   fired');
 const probe3 = createReflectiveCounter('Phone section fired');
</script>

<hr/>
<p><b>Greet User <mark><i>(with advanced on-screen diagnostics)</i></mark></b></p>

<p>
  <mark>{$probe1}:</mark>
  Hello {probe1.monitor() || $user.name}!</p>
<p>
  <mark>{$probe2}/{$probe3}:</mark>
  May we call you at:
  <i class:long-distance={probe2.monitor() || $user.phone.startsWith('1-')}>
    {probe3.monitor() || $user.phone}
  </i>?
</p>

<style>
 .long-distance {
   background-color: pink;
 }
</style>
```

You can run this version of the [Demo REPL] by selecting: <mark>with advanced on-screen diagnostics</mark>.

<!--- SCREEN PRINT: GreetUser_onScreenProbesA.png - show on-screen probes (selecting 'with advanced on-screen diagnostics') ---> 
<p align="center"><img width="50%" alt="On Screen Probes" src="https://dev-to-uploads.s3.amazonaws.com/i/9usvx4xj0nm4ssstjgvs.png"></p>

**Great** ... our component's reactivity is now visible, directly on our page!





<!---*** Section ***************************************************************---> 
## Re-Render Analysis

So there seems to be some **unexpected results**, revealed through the introduction of our diagnostic probes.  _We are seeing html-snippets re-execute when their state did NOT change **(ouch)**!_

<!--- SCREEN PRINT: GreetUser_unneededReFiresA.png - highlight logs/probes with no-change but re-fired (selecting 'with advanced on-screen diagnostics') ---> 
<p align="center"><img width="50%" alt="NO Changes, but still re-fired" src="https://dev-to-uploads.s3.amazonaws.com/i/ja62w2kxt6lbfbm13dd0.png"></p>

You can see this by changing a single property _(say name)_, and notice that all three of our html-snippets re-execute!  You can even click `Apply Change` button with no property changes, and still ... all three of our html-snippets re-execute!  _**SideBar**: I realize I can optimize the `user` store to prevent this last scenario, but for the purposes of this discussion, it better highlights the point we are driving at._

_**So what is going on?**_


<!---*** Sub-Section ***************************************************************---> 
### Dereferencing Objects

If you remember our discussion of [Reactive Triggers], this is actually an example of an object reference being overly broad in it's dependency granularity.

```html
<p>Hello {$user.name}!</p>
```

Because Svelte has marked the `$user` object as being stale, any html-snippet that references that object will re-execute, regardless of whether the dereferenced `.name` has changed or not!

At first glance, this **seems counter intuitive**.  _Why would Svelte do this?_ **Is this in fact causing redundant and unnecessary re-renders in our DOM**? ... _**Spoiler Alert**: No redundant re-renders are occurring, but we will discuss this in the next section!_

Well if you stop and think about this, in order for Svelte to monitor an object's dereferenced content, it would have to pre-execute sub-expressions found within the snippet, and monitor the resulting value.

In our simple example, that may technically be possible, but as a general rule this is a bad idea, for a variety of reasons.

The primary reason being that in order to accomplish this, these sub-expressions **would always need to be executed**, and that goes against the basic tenet of what Svelte is trying to do (i.e. it's reactive triggering mechanism) ... that is: _Should this snippet be re-executed or not?_ If Svelte had to pre-execute parts of the snippet to make this determination, there could be negative side-effects!  For example, the sub-expression could be invoking a method that applies unwanted mutations, etc.

**SideBar**: My explanation here is my "best guess", based on intuition.  If I receive comments from "in the know" Svelte maintainers, I will make any needed corrections (to the explanation) and remove this SideBar :-) Regardless of the the explanation, this is in fact how Svelte works!


<!---*** Sub-Section ***************************************************************---> 
### Svelte's Re-Render Optimization

_**So what does this mean?**_

The "elephant in the room" is: **<mark>Is this actually producing redundant and unnecessary re-renders in our DOM?</mark>** Remember: **DOM updates are expensive**!  Is this really true, _or is there more going on "under the covers"_?

It occurred to me that just because Svelte decided to re-execute my html-snippet, doesn't necessarily mean that it resulted in a DOM update.

Could it be that Svelte further optimizes this process by insuring the result of an html-snippet actually changed?  If you think about it, this makes a lot of sense for Svelte to do.

- In this particular case, an unnecessary html-snippet re-executed because of an overly broad dependency granularity ... i.e. an object verses it's individual content _(we discussed this in the [Reactive Triggers] section)_.

- There are other cases, however, where our html-snippet could return the same result, even when it's dependencies legitimately change.  Think about it: this is application code _(outside the control of Svelte)_.  Consider a case where our app requirements will group a set of enumerated values in to one classification, generating the same result from multiple values.

As it turns out, **<mark>Svelte does in fact optimize it's DOM updates by insuring the content has actually changed</mark>** ... _so there are no redundant re-renders_!


**Svelte comes to our rescue once again**!

I initially determined this by **going into a debugging session of one of my diagnostic probes**.

- By stepping out one level _(into the Svelte world)_, I found myself in some rather cryptic code, where a rather complex conditional was executing a helper function that actually performed the low-level DOM update.

- Being a little uncertain about this complex conditional, I decided to merely set a break-point on that helper function.

- This allowed me to interact with my app, and determine that: **sure enough** ... _the **DOM fragments only update (i.e. re-render) when the the result of the html-snippet actually changed**_!


**THIS IS SOOO KOOOL**!



<!---*** Sub-Section ***************************************************************---> 
### Svelte Compiler Output

OK, **now I was starting to get cocky**.  I started wondering: _how efficient is Svelte in making this "content change" determination_?  I kept thinking more about this cryptic code where I found myself _(in the debugging session)_:

> Could it be that this code was the output of the Svelte compiler?  ... You know, that **"JS output"** REPL tab, that you were **always afraid to click on**?

**Sure enough my hunch was right**!

With this newfound confidence, **dare I attempt to make sense of this cryptic code**? ... _well it's worth a try_!

**<mark>Caveat</mark>**: This section is **completely optional**.  We have already discussed the key takeaway that you need to know on this topic.  Therefore, **this section is strictly for <mark>extra credit only</mark>** _(albeit very interesting to real geeks)_!  Feel free to skip ahead to the [next section](#sveltes-reflexivity-is-very-efficient).

**FYI**: I won't clutter up the article with a lot of this cryptic code ... you can follow along by viewing the **"JS output"** tab from the [Demo REPL] (use the `GU1_original.svelte` module).

_So here goes ..._

**Cryptic Names:**

The first thing you will notice is that the variable names in this code aren't incredibility intuitive ... mostly numbered variables with single letter prefixes.  But hey: this is machine-generated code! We wouldn't want lengthy, intuitive names bloating the size of our bundle!  Actually, once you get the hang of it, there are some useful patterns in the names ... _keep reading_.

**DOM Fragments:**

The most important takeaway of this code is that Svelte has managed to break down our html into fragments that can be re-built at the lowest level of our DOM tree.

**This is a crucial point**!  Once this has been accomplished, it becomes rather trivial to incrementally process change!

My intuition tells me that this is probably the most complex aspect of the compiler.

<!--- AI: PUBLISH to dev.to: bullets with blank lines ... 1. PREFIX subsequent group with TAB   2. BLANK LINES prefixed with "TAB &nbsp;" (EXCEPT AROUND CODE-SNIPPETS - BUT THEM RIGHT UP) ---> 

- For static html _(that does not vary)_, it even uses a simple approach of `innerHTML`.
	
	For example, this:
	```html
	<p><b>Greet User <mark><i>(original)</i></mark></b></p>
	```
	Generated this:
	```js
	p0 = element("p");
	p0.innerHTML = `<b>Greet User <mark><i>(original)</i></mark></b>`;
	```
	
	_**Now this, I can handle**_ :-)
	
- For dynamic html content _(driven by an html-snippet/interpolation)_, it further breaks down the html into the needed individual DOM elements _(which can be incrementally updated)_.
	
	For example, this:
	```html
	<p>Hello {$user.name}!</p>
	```
	Generated this:
	```js
	// from the c() method ...
	p1 = element("p");
	t4 = text("Hello ");
	t5 = text(t5_value);
	t6 = text("!");
	
	// from the m() method ...
	insert(target, p1, anchor);
	append(p1, t4);
	append(p1, t5);
	append(p1, t6);
	```
	
	Notice that for dynamic content, Svelte is keeping track of two things:
	- the `t5` text dom element
	- and the `t5_value` text content ... _**<mark>this must be the output of our html-snippet</mark>**_!


**Naming Conventions:**

Are you starting to get a feel for some of the naming conventions?

- `p` is for paragraph
- `t` is for text nodes
- etc.


**Component Methods:**

The component contains several methods.  In reviewing their implementation, I think I can infer the following characteristics:

```js
// appears to be initializing our internal state
c() {
  ... snip snip
}

// appears to be the initial build-up of our DOM
m(target, anchor) {
  ... snip snip
}

// appears to be the incremental update of our DOM fragments
// ... THIS IS THE KEY FOCUS OF OUR REACTIVITY (analyzed below)
p(ctx, [dirty]) {
  ... snip snip
}

// appears to be removing our DOM
d(detaching) {
  ... snip snip
}
```


**More on Naming Conventions:**

Hey ... these names are starting to make sense, once you realize we are playing the [Sesame Street Alphabet Game]!

- `c()` is for `constructor()`
- `m()` is for `mount()`
- `p()` is for `partiallyPutinProgressivePermutations()` ... _I obviously have **NO IDEA** on this one_ :-( [Mark] later informed me it stands for `update()` _(using the second letter)_, and provided a reference to a [Tan Li Hau resource](https://lihautan.com/compile-svelte-in-your-head-part-1/) ... _where was this when I needed it_? :-)
- `d()` is for `destroy()`
- There are a number of methods that are not operational (e.g. `i: noop`, etc.), so we obviously have NOT hit the more advanced cases with our very simple component :-)



**Incremental Updates:**

The primary method we are interested in is the `p()` method.  This is where the incremental DOM updates occur.  It is where I found myself in the debugging session, when I determined that the DOM updates were optimized.

- Notice it has 3 sections of code _(each prefixed with a conditional - `if`)_

- WowZee ... our component definition also has 3 html-snippets _<mark>(what a coincidence)</mark>_!

<!--- AI: PUBLISH to dev.to: bullets with blank lines ... 1. PREFIX subsequent group with TAB   2. BLANK LINES prefixed with "TAB &nbsp;" (EXCEPT AROUND CODE-SNIPPETS - BUT THEM RIGHT UP) ---> 

- Let's look at one of them _(I have reformatted the JS just a bit, and added the `//` comments)_:
	
	**html code fragment**
	```html
	<p>Hello {$user.name}!</p>
	```
	
	**compiled output**
	```js
	p(ctx, [dirty]) {
	  // one of 3 sections ...
	  if (dirty & /*$user*/ 1 &&                                  // conditional Part I
	      t5_value !== (t5_value = /*$user*/ ctx[0].name + "")) { // conditional Part II
	    set_data(t5, t5_value);                                   // the payload - update the DOM!
	  }
	  ... snip snip
	},
	```

Here is my analysis:

- `ctx[]` array contains all our dependencies.  `ctx[0]` happens to be our `$user` object _(thanks to the compiler retained comment hints)_.

- `dirty` contains a bitwise accumulation of the "staleness" of ALL our dependent variables _(one bit for each dependent)_.

- Part I of the conditional is pulling out the dirty flag of the `$user` dependent variable _(using the bit-wise AND operator - `&`)_.  This determines if our `$user` variable is stale.  If it is, we will continue on to Part II (via the `logical-AND` operator - `&&`).

- Part II of the conditional is actually doing two things: It is assigning the latest `t5_value` from our html-snippet _(after converting it to a string: `+ ""`)_, **AND** it is comparing the prior/next snippet output (using identity semantics: `!==`).  Only when the prior/next has changed will it execute the conditional payload _(i.e. **update the DOM**)_.  Ultimately this conditional is a very simple primitive string comparison!

- The `set_data()` function is a Svelte helper utility that actually updates the DOM!  You can find these utils [on GitHub here](https://github.com/sveltejs/svelte/blob/master/src/runtime/internal/dom.ts), or simply open them from your installed `node_modules/svelte/internal/index.js`.  This particular utility merely sets the supplied data in a DOM text element:

  ```js
  function set_data(text, data) {
    data = '' + data;
    if (text.data !== data)
      text.data = data;
  }
  ```


<!---*** Sub-Section ***************************************************************---> 
### Svelte's Reflexivity is Very Efficient

Well that was fun!  _A very interesting exercise_! **What have we learned**?

- Don't be afraid to open the **"JS output"** tab of your REPL!

- Big Bird would do well in a Svelte code review!

- **Most importantly**, _the following insight_:


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Insight</mark>: Svelte's reflexivity is very efficient!

> The component's DOM representation is highly optimized, broken down into fragments that can be re-built at the lowest level of our DOM tree.
>
> Dynamic content is gleaned from executing html-snippets.
>
> Reflection is triggered by dependent state changes.
> 
> DOM updates occur only when the content has actually changed _(using a very light-weight string comparison)_!

**Who could ask for anything more**?

**Kudos** go out to [Rich Harris] and the [Core Contributors] for being so smart and thorough!







<!---*** Section ***************************************************************---> 
## App Reactivity Tweaks

We have learned that there is a subtle distinction between **reflection** _(Svelte's execution of html-snippets)_ and **re-rendering** _(applying DOM updates)_.

Just because Svelte has decided to run an html-snippet _(through it's dependency monitoring)_, doesn't mean that a DOM update is applied _(although it typically is)_ ... _because the snippet could return the same result_.  Svelte optimizes this process to insure DOM updates only occur when they actually change.

As a result, our reflection count can be slightly larger than the re-rendering count.  There are two reasons for this:

1. An overly broad dependency granularity _(e.g. the difference between objects and primitives)_.  This one is on the shoulders of Svelte.  As an example, Svelte has invoked our snippet because of an object change, but the object's sub-content _(used by our snippet)_ hasn't really changed.  We will discuss this further in: [Finer Grained Dependency Management]

2. The html-snippet could return the same result for multiple dependent values. This is on the shoulders of our App.  Consider the case where our app requirements will group a set of enumerated values in to one classification, generating the same result from multiple values.  We will discuss this further in: [Preresolve Variations]

Regardless of who's shoulders these conditions emerge, **there are app-specific techniques by which we can narrow this gap** _(even to zero)_.  So how can we impact this?  After all, Svelte is the one who is in control of executing our html-snippets.  How can we alter this?

The basic thrust of what we are about to do is to **move a portion of our reflexivity FROM html-snippets TO code-snippets**.  Remember, we mentioned that code-snippets typically have less overhead _(because they merely result in changes to JavaScript state variables)_.

Why would you want to do this?  Does it really represent a significant optimization?  Well, consider this:

1. What if this discrepancy count were large _(where we were needlessly re-executing an html-snippet many times with the same output)_?
2. And what if the overhead of executing this html-snippet were extremely high?
3. What if the same html-snippet were needed in multiple places in our html?

Keep in mind, we do not have these conditions in our simple toy app ... but for sake of example, let's pretend that we do!

Regarding the optimization question ... to be honest, most likely the techniques we are about to discuss will not significantly impact your app's performance.  In some cases, we will just be moving an optimization that Svelte was already doing, into the application realm.  With that said, the best opportunity for an optimization is bullet point 3 (above).

So why go through this exercise?  Very simply: _**<mark> to better understand the finer characteristics of Svelte's reactivity</mark>**_!  This knowledge can give you the edge that separates the senior developers ... knowing the impact of finer-grained tweaks ... pulling in the big bucks ... _we can only hope_!


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets

> The overhead of **code-snippets** are typically very light, because they merely change JavaScript state variables.
>
> While it is true that variable changes can result in html DOM changes _(by stimulating a dependent **html-snippet**)_, this will be canceled out, when the dependent variable is unchanged _(within the **code-snippet**)_.




<!---*** Sub-Section ***************************************************************---> 
## Finer Grained Dependency Management

This section addresses Svelte's overly broad dependency granularity, as it relates to [Primitive Types] verses [Object Types].

Our `GreetUser` component is currently dereferencing the `$user` object within it's html.  This is causing Svelte to execute our html-snippets in cases where the dereferenced property has not changed.

We can change this by simply normalizing our referenced state into primitive types.


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Takeaway</mark>: Fine Tune Svelte's Dependency Management by using primitive types

> When an html-snippet dereferences an object that has the potential of changing (e.g. `user.name`), this may result in a false-positive condition.
>
> Svelte will re-execute the snippet based on whether the top-level object has changed (e.g. `user`), and not the dereferenced result!
>
> You can change this by depending on primitive types _normalized from the object (say through a code-snippet)_, giving the html-snippet finer granularity in what triggers it's execution.
>
> html-snippets that depend on primitive types will only execute when their dependent values change _(based on identity semantics)_.
>
> This is really an application of the [<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets].


Here is our `GreetUser` component with the applied change:

<!--- a code version with: with primitive normalization ---> 
**GreetUser.svelte** _(see `GU4_primNorm.svelte` in [Demo REPL])_
```html
<script>
 import user from './user.js';
 import createReflectiveCounter from './createReflectiveCounter.js';

 // FOCUS: with primitive normalization
 // normalize our referenced state with primitive types
 // ... html-snippets will only fire when values actually change
 // ... using JS identity semantics
 $: ({name, phone} = $user);

 // diagnostic probes monitoring reflection
 const probe1 = createReflectiveCounter('Name  section fired');
 const probe2 = createReflectiveCounter('Phone class   fired');
 const probe3 = createReflectiveCounter('Phone section fired');
</script>

<hr/>
<p><b>Greet User <mark><i>(with primitive normalization)</i></mark></b></p>

<p>
  <mark>{$probe1}:</mark>
  Hello {probe1.monitor() || name}!</p>
<p>
  <mark>{$probe2}/{$probe3}:</mark>
  May we call you at:
  <i class:long-distance={probe2.monitor() || phone.startsWith('1-')}>
    {probe3.monitor() || phone}
  </i>?
</p>

<style>
 .long-distance {
   background-color: pink;
 }
</style>
```

You can run this version of the [Demo REPL] by selecting: <mark>with primitive normalization</mark>.

<!--- SCREEN PRINT: GreetUser_fixDeReferencingA.png - highlight object dereferencing fix (selecting 'with primitive normalization') ---> 
<p align="center"><img width="50%" alt="No Changes, NO re-fire ... FIXED" src="https://dev-to-uploads.s3.amazonaws.com/i/xcy8ejg8rq18f7a0qx6p.png"></p>

**Great**: Notice that the **reflection counts** _(Svelte's execution of html-snippets)_ now correctly reflect actual changes to the corresponding state!

In this example, the "primitive normalization" was accomplished in the component code-snippet:

```js
$: ({name, phone} = $user);
```

When the `$user` object changes, this normalization code will be re-executed.  However, because our html-snippets utilize the `name`/`phone` primitives, **only the snippets that depend on the properties that truly changed will re-execute! ... _very kool!_**

This "primitive normalization" can be accomplished in a variety of ways.  In our example, it was carried out in the component code.  Another way you could accomplish this is to **promote derived stores**, that pull a single value out.  For example:

**user.js** _(modified)_
```js
import {writable, derived} from 'svelte/store';

export const user = writable({
  name:  '',
  phone: '',
});

export const name  = derived(user, (u) => u.name);
export const phone = derived(user, (u) => u.phone);
```


<!---*** Sub-Section ***************************************************************---> 
## Preresolve Variations

This section addresses the case where an html-snippet generates the same result for multiple dependent values.  This typically occurs when the snippet contains conditional logic.

In our example, long distance phone numbers will be highlighted _(when they begin with "1-")_.  This is accomplished by conditional logic in the html-snippet:

```html
<i class:long-distance={phone.startsWith('1-')}>
  ... snip snip
</i>
```

The issue here is that Svelte will re-execute the html-snippet based on whether the dependent `phone` changes, irrespective of whether the CSS class will change.

You can see this in the demo by changing the latter part of the phone number (keeping the prefix intact):

<!--- SCREEN PRINT: GreetUser_issueConditionalsA.png - highlight conditionals issue (selecting 'with primitive normalization') ---> 
<p align="center"><img width="50%" alt="Long distance NOT changed, but still re-fired" src="https://dev-to-uploads.s3.amazonaws.com/i/ycz0lttcxh65rypk80xm.png"></p>

As you can see, this resulted in a higher number of **reflection counts** _(Svelte's execution of html-snippets)_.

**Solution:**

If we were to move this logical condition into a code-snippet, the resulting html-snippet would result in fewer executions!


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Takeaway</mark>: Fine Tune conditional logic by moving html-snippet variations into code-snippets

> By allowing conditional expressions to be resolved in a code-snippet, the resulting html-snippet will fire less often.
> 
> This is really an application of the [<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets].

Here is our `GreetUser` component with the applied change:

<!--- a code version with: with primitive normalization ---> 
**GreetUser.svelte** _(see `GU5_variations.svelte` in [Demo REPL])_
```html
<script>
 import user from './user.js';
 import createReflectiveCounter from './createReflectiveCounter.js';

 // normalize our referenced state with primitive types
 // ... html-snippets will only fire when values actually change
 // ... using JS identity semantics
 $: ({name, phone} = $user);

 // FOCUS: with variations in code
 // by allowing conditional expressions to be resolved in a code-snippet,
 // the resulting html-snippet will fire less often.
 $: classes = phone.startsWith('1-') ? 'long-distance' : '';

 // diagnostic probes monitoring reflection
 const probe1 = createReflectiveCounter('Name  section fired');
 const probe2 = createReflectiveCounter('Phone class   fired');
 const probe3 = createReflectiveCounter('Phone section fired');
</script>

<hr/>
<p><b>Greet User <mark><i>(with variations in code)</i></mark></b></p>

<p>
  <mark>{$probe1}:</mark>
  Hello {probe1.monitor() || name}!</p>
<p>
  <mark>{$probe2}/{$probe3}:</mark>
  May we call you at:
  <i class="{probe2.monitor() || classes}">
    {probe3.monitor() || phone}
  </i>?
</p>

<style>
 .long-distance {
   background-color: pink;
 }
</style>
```

You can run this version of the [Demo REPL] by selecting: <mark>with variations in code</mark>.

<!--- SCREEN PRINT: GreetUser_fixConditionalsA.png - highlight conditionals fix (selecting 'with variations in code') ---> 
<p align="center"><img width="50%" alt="Long distance NOT changed, NO re-fire ... FIXED" src="https://dev-to-uploads.s3.amazonaws.com/i/eduo8c5m75pyfyyjep7l.png"></p>

**Great**: Notice that the **reflection counts** _(Svelte's execution of html-snippets)_ now correctly reflects whether the CSS class actually changed!

In this rendition, the variability is now accomplished in the component code-snippet:

```js
$: classes = phone.startsWith('1-') ? 'long-distance' : '';
```

As a result, the html-snippet will only execute when the `classes` variable actually changes.



<!---*** Section ***************************************************************---> 
## Optimization Caveats

Here are a couple of "extras" to consider regarding optimization:


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Insight</mark>: Optimization is only relevant when reactivity occurs for active components

> The initial render of a component _(i.e. when it is mounted)_ will unconditionally execute all it's html-snippets _(regardless of dependencies, or conditionals)_.
>
> If there is no reactivity after this, then there is no need to be concerned with these optimization techniques.
>
> Keep in mind however, that reactivity can sometimes be difficult to predict.  In addition, future revisions to your code may introduce reactivity.  **So be careful!** It doesn't hurt to always follow these techniques.


<!---*** TAKEAWAY/INSIGHT *****************************************************---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 
#### <mark>Insight</mark>: Optimization is preferred but optional

> If you neglect to follow these optimization techniques, your app will still work correctly.  It just won't be as performant as it could be.




<!---*** Section ***************************************************************---> 
## Extra Credit Exercise

For those who would like some **extra credit**, let me propose an enhancement to our `ReflectiveCounter` _(discussed in [Advanced Diagnostics])_.

In it's current form, the `ReflectiveCounter` is providing us a **reflexive count** _(the html-snippet execution count)_.

Can you think of a way that it could provide both **reflexive counts** -and- **re-render counts** _(that is ... of the DOM updates)_?

This little exercise should _**separate the Geeks from the wannabes**_!

I won't give you the solution directly, but here is a **very big hint** ...  The invocation will change:

**FROM:**
```html
<i>{fooProbe.monitor() || $foo}</i>
```

**TO:**
```html
<i>{fooProbe.monitor( () => $foo )}</i>
```

**Are you up for the challenge?** FYI: There is a hidden easter egg _(tucked away somewhere)_ that reveals the solution!  If you can't find it, just **ping me in the comments below**.




<!---*** Section ***************************************************************---> 
## Who is this guy?

Just to give you a little of my background _(as it relates to software engineering)_...

I have been in the software industry for over 40 years.  I'm probably the **old guy in the room** _(retired since 2015)_.  I like to say that _**I am a "current" developer from a different era**_, but gee whiz, it is getting harder and harder to stay current!  Case in point: _I'm just now learning Svelte, which has been out **how long**_?

Needless to say, I cut my "programming teeth" 25 years before there was a usable internet _(in the mid 70's)_.

I remember the great computing pioneer, [Grace Hopper] as a visiting lecturer, who at the age 73 imparted the computing insights of the day _(which at it's core, wasn't all that different from today)_.  She used great visual aids ...  **passing out [nanoseconds]**, etc.  Admiral Hopper was a senior way back then _(in the mid 70's)_, so I suppose I shouldn't be too self conscious :-) **Trivia point**: _she also coined the term: **[bug]**_!

When I eventually started web-development _(in the mid 90's)_, I was "all in" for this new [Netscape] technology called JavaScript!  Even back then, we were providing reactivity at a page level, using this new innovation.

Over the years I have written a number of large-scaled SPAs _(predating the SPA term)_, using pure JavaScript _(i.e. there were no frameworks)_!  Believe me, providing large-scaled app-based reactivity is a daunting task, requiring some good underlying architecture, and ultimately a lot of code!

I actually skipped right over the jQuery phenomenon, and went straight into the new declarative frameworks ... first Angular, then React.  This declarative approach never ceases to amaze me ... _**in realizing how much can be accomplished with so little code**_ :-)

**Svelte merely takes this progression to the next level**!  It provides all the benefits of a declarative approach, without the bloated in-memory run-time framework!

I have been contributing to open source since my retirement _(in 2015)_.  My most recent offering is a product called [feature-u]: _a React utility that facilitates **Feature-Driven Development**_.

I am a **brand spanking new Svelter**!

My first Svelte project _(too early to publish)_ is a re-creation of my most prized project _(in the early 90's)_.  It was an "Engineering Analysis" tool, written in C++ under Unix/X-Windows.  It had:

- schematic capture: with multiple functional decompositions of the master schematic
- executable control laws: through graphical flow diagrams that were executable
- simulation: driven by the control laws (animating one or more of the schematics and control laws)
- a symbolic debugger: also driven by the control laws
- auto generation of the embedded system code (derived from the executable control laws)
- Needless to say, this system has **reactivity on steroids**!

You can find me [On The Web](https://wiibridges.com), [LinkedIn](https://www.linkedin.com/in/kevinbridges), [Twitter](https://twitter.com/kevinast), and [GitHub](https://github.com/KevinAst).




<!---*** Section ***************************************************************---> 
## Summary

Well, this turned out to be a much "deeper dive" than what I had initially envisioned :-) We have covered a lot!  I hope you enjoyed this little journey, and learned something as well!

**A big thanks** goes out to [Rich Harris] and the [Core Contributors] for making Svelte such an awesome product!  I can't wait to see what the future holds in the next release!

Happy Computing,

`</Kevin>`

**P.S.** For your convenience, I have summarized my findings here.  Each point contains a short synopsis, and is linked to the more comprehensive discussion.


<!--- AI: PUBLISH to dev.to: bullets with blank lines ... 1. PREFIX subsequent group with TAB   2. BLANK LINES prefixed with "TAB &nbsp;" (EXCEPT AROUND CODE-SNIPPETS - BUT THEM RIGHT UP) ---> 
<!--- SHORTCOMING: dev.to: only decent way of indenting is with blockquote ... REFORMATTING IS TEDIOUS :-( ---> 

1. [<mark>Terminology</mark>: snippet, code-snippet, and html-snippet]
	
	> Within this article, the term **snippet** refers to any JavaScript expression that Svelte reactively manages and invokes when it's dependent state changes.
	>
	> Snippets may either be:
	> - **code-snippets** _(referred to as **Reactive Declarations** and **Reactive Statements**)_ 
	> - or **html-snippets** _(commonly referred to as **interpolation**)_.  
	>
	> Ultimately, snippets provide the dynamics within our html markup _(i.e. it's reactivity)_.
	
2. [<mark>Insight</mark>: Reactivity is based on change in dependent state]
	
	> Snippet execution is triggered when dependent state changes
	>
	> - primitive types trigger reactivity only when the value changes _(based on identity semantics)_
	>
	> - objects trigger reactivity per the entire object, not individual content
	
3. [<mark>Takeaway</mark>: Monitor Svelte snippet invocations through logically-ORed prefixed expressions]
	
	> You can detect when Svelte executes a snippet by prefixing it with a **logically-ORed** monitor.
	> 
	> This can be a simple [logging probe] or a more advanced [ReflectiveCounter]
	
4. [<mark>Insight</mark>: Diagnostic probes are temporary]
	
	> Diagnostic probes should be considered temporary, and removed _(or commented out)_ when your analysis is complete.
	> 
	> There are techniques where they can be disabled at run-time _(with minimal overhead)_, but this exercise is left up to the reader.
	
5. [<mark>Insight</mark>: Svelte's reflexivity is very efficient!]
	
	> The component's DOM representation is highly optimized, broken down into fragments that can be re-built at the lowest level of our DOM tree.
	>
	> Dynamic content is gleaned from executing html-snippets.
	>
	> Reflection is triggered by dependent state changes.
	> 
	> DOM updates occur only when the content has actually changed _(using a very light-weight string comparison)_!
	
6. [<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets]
	
	> The overhead of **code-snippets** are typically very light, because they merely change JavaScript state variables.
	> 
	> While it is true that variable changes can result in html DOM changes _(by stimulating a dependent **html-snippet**)_, this will be canceled out, when the dependent variable is unchanged _(within the **code-snippet**)_.
	
7. [<mark>Takeaway</mark>: Fine Tune Svelte's Dependency Management by using primitive types]
	
	> When an html-snippet dereferences an object that has the potential of changing (e.g. `user.name`), this may result in a false-positive condition.
	>
	> Svelte will re-execute the snippet based on whether the top-level object has changed (e.g. `user`), and not the dereferenced result!
	>
	> You can change this by depending on primitive types _normalized from the object (say through a code-snippet)_, giving the html-snippet finer granularity in what triggers it's execution.
	>
	> html-snippets that depend on primitive types will only execute when their dependent values change _(based on identity semantics)_.
	> 
	> This is really an application of the [<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets].
	
8. [<mark>Takeaway</mark>: Fine Tune conditional logic by moving html-snippet variations into code-snippets]
	
	> By allowing conditional expressions to be resolved in a code-snippet, the resulting html-snippet will fire less often.
	> 
	> This is really an application of the [<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets].
	
9. [<mark>Insight</mark>: Optimization is only relevant when reactivity occurs for active components]
	
	> The initial render of a component _(i.e. when it is mounted)_ will unconditionally execute all it's html-snippets _(regardless of dependencies, or conditionals)_.
	> 
	> If there is no reactivity after this, then there is no need to be concerned with these optimization techniques.
	> 
	> Keep in mind however, that reactivity can sometimes be difficult to predict.  In addition, future revisions to your code may introduce reactivity.  **So be careful!** It doesn't hurt to always follow these techniques.
	
9. [<mark>Insight</mark>: Optimization is preferred but optional]
	
	> If you neglect to follow these optimization techniques, your app will still work correctly.  It just won't be as performant as it could be.




<!--- AI: PUBLISH to dev.to: ALL-BELOW: REMOVE dash from #link ... dev.to INCORRECTLY drops dashes (-) ---> 
<!--- links ---> 
[TL;DR]:                                    #tldr
[Video Presentation]:                       #video-presentation
[Svelte Reactivity]:                        #svelte-reactivity
[Reactive Triggers]:                        #reactive-triggers
  [Primitive Types]:                        #primitive-types
  [Object Types]:                           #object-types
  [Staleness Summary]:                      #staleness-summary
[Exploring App Reactivity]:                 #exploring-app-reactivity
  [Diagnostic Logging Probes]:              #diagnostic-logging-probes
  [Advanced Diagnostics]:                   #advanced-diagnostics
[Demo App]:                                 #demo-app
[Inspecting App Reactivity]:                #inspecting-app-reactivity
  [Logging Probes]:                         #logging-probes
  [Advanced Probes]:                        #advanced-probes
[Re-Render Analysis]:                       #rerender-analysis
  [Dereferencing Objects]:                  #dereferencing-objects
  [Svelte's Re-Render Optimization]:        #sveltes-rerender-optimization
  [Svelte Compiler Output]:                 #svelte-compiler-output
  [Svelte's Reflexivity is Very Efficient]: #sveltes-reflexivity-is-very-efficient
[App Reactivity Tweaks]:                    #app-reactivity-tweaks
  [Finer Grained Dependency Management]:    #finer-grained-dependency-management
  [Preresolve Variations]:                  #preresolve-variations
  [Optimization Caveats]:                   #optimization-caveats
[Extra Credit Exercise]:                    #extra-credit-exercise
[Who is this guy?]:                         #who-is-this-guy
[Summary]:                                  #summary

[logging probe]:      #diagnostic-logging-probes
[ReflectiveCounter]:  #advanced-diagnostics

[Demo REPL]:              https://svelte.dev/repl/1385ee3b3ca64f8db38c12404df3e6ca?version=3.24.0
[Reactive Triggers REPL]: https://svelte.dev/repl/801a0a6bdc1f4ea08134425c18bb3e80?version=3.24.0

[Svelte]:             https://svelte.dev/
[Mark Volkmann]:      https://twitter.com/mark_volkmann
[Mark]:               https://twitter.com/mark_volkmann
[Rich Harris]:        https://twitter.com/Rich_Harris
[Core Contributors]:  https://github.com/sveltejs/svelte/graphs/contributors

[Grace Hopper]:                https://en.wikipedia.org/wiki/Grace_Hopper
[nanoseconds]:                 https://americanhistory.si.edu/collections/search/object/nmah_692464
[bug]:                         https://www.atlasobscura.com/places/grace-hoppers-bug
[Sesame Street Alphabet Game]: https://muppet.fandom.com/wiki/The_Alphabet_Game

[Netscape]:  https://en.wikipedia.org/wiki/Netscape
[feature-u]: http://bit.ly/feature-u-teaser


<!--- TAKEAWAY/INSIGHT links, can have the highlighted marks in [] your choice ---> 
<!--- AI: PUBLISH to dev.to: ALL-BELOW: REMOVE #mark...mark-bla-bla ---> 
<!--- AI: PUBLISH to dev.to: ALL-BELOW: REMOVE dash from #link ... dev.to INCORRECTLY drops dashes (-) ---> 

<!--- AI: PUBLISH for your convenience I am maintinaing TWO versions ---> 

<!--- REAL MARKDOWN:
[<mark>Terminology</mark>: snippet, code-snippet, and html-snippet]:                                        #markterminologymark-snippet-code-snippet-and-html-snippet
[<mark>Insight</mark>: Reactivity is based on change in dependent state]:                                   #markinsightmark-reactivity-is-based-on-change-in-dependent-state
[<mark>Takeaway</mark>: Monitor Svelte snippet invocations through logically-ORed prefixed expressions]:    #marktakeawaymark-monitor-svelte-snippet-invocations-through-logically-ored-prefixed-expressions
[<mark>Insight</mark>: Diagnostic probes are temporary]:                                                    #markinsightmark-diagnostic-probes-are-temporary
[<mark>Insight</mark>: Svelte's reflexivity is very efficient!]:                                            #markinsightmark-sveltes-reflexivity-is-very-efficient
[<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets]:               #markextreme-optimizationmark-prefer-reactivity-in-code-snippets-verses-html-snippets
[<mark>Takeaway</mark>: Fine Tune Svelte's Dependency Management by using primitive types]:                 #marktakeawaymark-fine-tune-sveltes-dependency-management-by-using-primitive-types
[<mark>Takeaway</mark>: Fine Tune conditional logic by moving html-snippet variations into code-snippets]:  #marktakeawaymark-fine-tune-conditional-logic-by-moving-html-snippet-variations-into-code-snippets
[<mark>Insight</mark>: Optimization is only relevant when reactivity occurs for active components]:         #markinsightmark-optimization-is-only-relevant-when-reactivity-occurs-for-active-components
[<mark>Insight</mark>: Optimization is preferred but optional]:                                             #markinsightmark-optimization-is-preferred-but-optional
 ---> 

<!--- dev.to dillweed: ---> 
[<mark>Terminology</mark>: snippet, code-snippet, and html-snippet]:                                        #terminology-snippet-codesnippet-and-htmlsnippet
[<mark>Insight</mark>: Reactivity is based on change in dependent state]:                                   #insight-reactivity-is-based-on-change-in-dependent-state
[<mark>Takeaway</mark>: Monitor Svelte snippet invocations through logically-ORed prefixed expressions]:    #takeaway-monitor-svelte-snippet-invocations-through-logicallyored-prefixed-expressions
[<mark>Insight</mark>: Diagnostic probes are temporary]:                                                    #insight-diagnostic-probes-are-temporary
[<mark>Insight</mark>: Svelte's reflexivity is very efficient!]:                                            #insight-sveltes-reflexivity-is-very-efficient
[<mark>Extreme Optimization</mark>: Prefer reactivity in code-snippets verses html-snippets]:               #extreme-optimization-prefer-reactivity-in-codesnippets-verses-htmlsnippets
[<mark>Takeaway</mark>: Fine Tune Svelte's Dependency Management by using primitive types]:                 #takeaway-fine-tune-sveltes-dependency-management-by-using-primitive-types
[<mark>Takeaway</mark>: Fine Tune conditional logic by moving html-snippet variations into code-snippets]:  #takeaway-fine-tune-conditional-logic-by-moving-htmlsnippet-variations-into-codesnippets
[<mark>Insight</mark>: Optimization is only relevant when reactivity occurs for active components]:         #insight-optimization-is-only-relevant-when-reactivity-occurs-for-active-components
[<mark>Insight</mark>: Optimization is preferred but optional]:                                             #insight-optimization-is-preferred-but-optional