API change for rerender

Continuing from #28

Instead of asking the developer to import rerender and manually wire it with args.element, you could just pass this to the render callback as the third argument, so the developer doesn’t need to know about args.element (all they care about is causing their component to rerender).

So the render callback would look like:

...
return {
    render(props, args, rerender) {   // rerender is already primed with args.element so the dev doesn't need to wire it themselves
...
rerender() // <- didn't need to pass args.element

So to achieve that you just need to wrap the rerender function sth like:

  // Get a new element by calling render on existing component.
        const newForgoNode = newComponentState.component.render(
          forgoElement.props,
          newComponentState.args,
          () => rerender(newComponentState.args.element)) // this third argument can now be called in userland by simply calling rerender() provided as the third argument of the callback
        );

[jeswin]

I do agree.

I think my initial hesitation (and I suspect Jacob’s) was that:

1. We haven’t done obj.method() in the user facing API till now - either as a class method or as a function that closes over some value. Users can always expect - func(someArg).
2. PEP 20: There should be one-- and preferably only one --obvious way to do it.
3. Your suggestion of having the 3rd param (a rerender func closed over args) also had merit; it avoids the x.func() syntax which we have now on args.update(). But the problem with that was - a) How do we know in these early days whether it deserves to be the third param? b) If something else came up, this sets up precedent for fourth param. So it’s too early to decide.

But in the end, update() with destructuring makes for very clean code; and spares the user from learning about args.element. The exception was worth it.

Still have to figure out how to document this - it makes no sense to throw in two styles of update. But it’s WIP.

[jeswin]

Again, on the other hand again, I don’t want rerender to be the name of the property and the import from forgo. This is asking for your users to file stupid issues calling the wrong rerender.

This is a good point.

It’s really a toss up for me, but the power of how forgo can force rerenders up and down the tree, not just your own component subtree is one of the things that drew me in. This is kind of masking that for your general user and I do not think it makes it any better.

This is also a good point. But knowing how to wield rerender() to force a rerender up the tree (by adjusting the componentIndex) might also be an advanced use case - mostly used by expert users.

I asked a few people who are largely unfamiliar with forgo, and for new users it seems rerender() without args is less confusing. One additional point of confusion (for them) is that args.element is not a DOM element, but a structure which identifies a Forgo element.

Now I agree on two things:

1. Of course, we’ll retain the rerender(args.element). That’s set in stone.
2. The new property must not be called rerender()