Conditional for rendering

[visj]

Hey Ryan!

I've resumed my work on researching efficient rendering strategies for conditional paths. I tried to create a benchmark between Solid and Ivi looking at conditionals inside map. Below is an example code:

<Show when={state.done === false}>
  <For each={array}>
    {x => {
      return <For each={array}>
        {y => {
	  if (x > y) {
	    return <div>Ok</div>
	  }
	  return null;
        }}
      </For>
    }}
  </For>
</Show>

How did you approach this? Basically, if you have a map -> condition -> map -> condition situation, do you render it inside out or outside in?

[ryansolid]

My For uses mapSample so callbacks are not tracking, There are ways to get ternaries to work with fragments/createMemo but for your purposes Id use Show helper component assuming you want this to be dynamic.

I'm interested in what you find. Direct cascading control flows, like Fragments produce the most potential for de-opt. My original approach here might have been the most performant but it was super complex, where I was basically virtualizing fragments throughout the tree. My newer approach basically attempts to normalize the whole array so while it is shallow comparisons.. there are definitely places where I do more checks than theoretically needed. It was a good balance for code size, and made Solid even faster in the simple cases, but I do wonder just how much this gives up.

[ryansolid]

Actually looking at your example does x/y ever change? If not what you have should be fine. In this case, I do render outside in since I can't prematurely create things we won't use.

[visj]

I had some trouble setting up Solid and getting it to work. This was the example I tried to port from ivi.

const t1 = Date.now();

let done = false;
let array = [1,2,3,4,5,6,7,8,9,10];
let items = ['Hello', 'Some', 'Great', 'World'];

function App() {
	if (done) {
		setTimeout(function() {
			const t2 = Date.now();

			alert('Time elapsed: ' + (t2 - t1));
		});
		return 'Done';
	} else {
		return array.map(x => {
			return x < 2 ? null : array.map((x,i) => {
				if (i < 4) {
					return div(_, _, 'Larger than 4');
				} else if (i > 4 && i < 6) {
					return null;
				} else {
					return items.map((item, i) => {
						if (i > 1) {
							return div(_, _, item);
						}
						return null;
					});
				}
			});
		});
	}
}

const root = document.getElementById('app');

render(App(), root);

array = [11,12,13,14,15,16,17,18,19,20];
items = ['Some', 'Other', 'World', 'What'];

render(App(), root);

array = [1,6,1,7,2,8,1,9,12,14,1,15];
items = ['There', 'Is', 'Still', 'Hope'];

render(App(), root);

done = true;
render(App(), root);

[visj]

All right, yeah, I recognized the code from S array but helpful to know which approach you went for.

I created a few new repositories. You can track my progress there. Anod is basically a merge of S and S array, where I experiment with mutation propagation for array procedures. Haven't decided if I will purse tracking or subclocks there yet.

Also experimenting in isolit, creating a merge of a virtual dom and data binding approach. The idea is to set up an entire virtual dom and then only patch it from data bindings. So then we would basically have virtual nodes all the way down, something like

EnumerableOp -> childNodes Op[] -> ProcedureOp -> EnumerableOp etc.

[ryansolid]

I see they do change.. drastically too. Nothing shared. It basically re-renders everything if this is keyed. Is the intention for this to be keyed or non-keyed? With primitives like this, it feels you want non-keyed in which case I'd use <Index> instead of <For>. Like are you trying to replace everything, or re-use as much of the structure as possible?

Also experimenting in isolit, creating a merge of a virtual dom and data binding approach. The idea is to set up an entire virtual dom and then only patch it from data bindings.

Vue works something like this I think.

[visj]

The idea was to reuse very little (you see that some nodes can be reused in the last part). It's based on the example Boris had on Ivi (but I think it was dropped from docs upon 1.0), where he tested performance of conditional rendering in maps, where ivi basically had no performance penalty of conditionals as it doesn't matter from the virtual dom perspective. So I wanted to see how big of a slowdown the data driven approach has and how to mitigate it.

[ryansolid]

I see so this is keyed by the value not by the index? Like from initial to 2nd with how <For> works the whole thing gets re-rendered since [11-20] has no numbers from [1-10]. Where as <Index> would just update the data for those 10 rows but try to keep the structure in tact. The last example basically only gets to re-use 12, 14, 15, but the internal array is completely different so ultimately no DOM nodes remain intact in any of these examples.

Let me see if I can recreate this for you.

[ryansolid]

Ok not promising this is super optimized but I think I recreated the logic: https://codesandbox.io/s/ivi-example-zsopf?file=/index.js. Using indexes in <For> actually adds a memory overhead that I optimize out when not required. And <Switch> <Match> is likely not the most optimal way to do the conditional logic but it is definitely the easiest.

That all being said make sure you are testing the same thing. Keyed, vs non-keyed makes a big difference and I can't tell from the code if ivi is doing keyed or not.

I do suspect there will be overhead here as this example is pretty complicated logic-wise and the benchmark is basically doing snapshots so there is almost no benefit to even diffing. No partial updates either. Benefit of reactivity is to reduce work and this example there is basically no opportunity to.

I suspect a naive innerHTML would give both frameworks a run for their money. Even more exaggerated by only having single div insertion so the benefits of node cloning one of perf gains over VDOM which is more present in typical apps is lost here. Mind you if I wanted to come up with an example to showcase ivi this would be it.

[visj]

You're absolutely right. I will set up a repository with some more thought through benchmarks. Will definitively keep in mind keyed vs non-keyed.

By the way, it might interest you, but I have now pushed a much more performant tracing solution. It lazily evaluates tracing and opts for static dependency trees. Also entirely removes the awkward dependee part, and updates traces like subclocks, e.g. they always run before normal updates, so once they are run, we don't have to check upstream dependencies of downstream nodes as we know any tracking nodes have already been executed.

[visj]

I've setup my most current research in anod. It offers tracing computations and my idea of array mutation propagation. Would love to hear your thoughts about it!

Some powerful features involve tracing computations for all array operations, i.e., methods like .find will not trigger downstream computations unless changed. Also, by dispatching mutations, we can apply many of them in O(1) space instead of O(n). For instance, if we haven't found something last round and push a Deletion mutation, we know we won't find it this time either, and not only do we skip searching, we also skip propagating any change to downstream computations.

I've started adding docs to it as well. It's still a work in project and I'm trying to catch up on all required unit tests.

[ryansolid]

That is interesting. I was looking at this at one point and few others were working on this sort of thing like the author of crui(https://github.com/cruijs/crui). I sort of gave up and went to typical diffing for arrays but it is interesting. I looked at anod the yesterday but only on the surface. Looks like you have added more to the readme today so I will try to take a look tonight assuming everything else goes well.

[visj]

To ease your mind, here is where we apply mutations to map. I think you can easily imagine how to convert that logic into dom operations.