memo in createComponent

On the last line of this function it seems to be creating a memo in some situation. Although I tried to print it I had no luck using class components and even function components. So Im confused, that code runs at all?. I would like to have control about whats memoized and not memoized for in case of /render once/ . Whats the purpose of the memoizing? can it be removed please if the only purpose was to just memoize everything for the proof of concept. Thanks!

function createComponent(Comp, props, dynamicKeys) {
  console.log('creating compooent', Comp)
  if (dynamicKeys) {
    for (let i = 0; i < dynamicKeys.length; i++) dynamicProperty(props, dynamicKeys[i])
  }

  let c

  if (Comp.prototype && Comp.prototype.isClassComponent) {
    console.log('is class')
    c = (0, _mobx.untracked)(() => {
      const comp = new Comp(props)
      return comp.render(props)
    })
  } else {
    console.log('is not class')
    c = (0, _mobx.untracked)(() => Comp(props))
  }
  console.log('component is', c)
  return typeof c === 'function' ? memo(c) : c
}

[ryansolid]

Released in 0.11.7

[ryansolid]

While it’s possible to hit this scenario, unlike Solid which has control flow components, you are much more unlikely to. I intend to move more and more of this logic into compiler time, and since there are no cases today with shipped things that require this extra care and it’s an extra overhead I’m going to put things back to how they’ve always been before the latest versions of the library. Largely a lot of stuff becomes copy and paste from Solid and I didn’t give the specific library enough consideration.

Note to self: I need to still find the best balance. The challenge being only the insertion point needs to be wrapped which I can do mostly automatically at compile time with the exception of things that produce arrays with dynamic elements programmatically instead of through JSX. But since the libraries controls those array helpers I can modify them instead of pushing it on to end user who doesn’t know where their component will be used. In one sense the end user is the best to know if their creation is expensive and needs wrapping but that can lead to unnecessary levels of nested wrapping. But it is fairly safe to say any case where an array is constructed regardless of the lookup cost if direct indexes are dynamic we should be memorizing to prevent unnecessary re-evaluation between indexes. And only very specific transformations that involve accessing resolved values multiple times would need memorization in the middle.