Compatibility with dynamic imports

[lmartins]

Hi, thank you for this super useful library,
Have you played with adding the ability for the library to also deal with dynamic imports?

I'm using the feature provided by Webpack, which when passed to the picoapp instance it doesn't initiate the lazyloaded module.

Thank you!

[estrattonbailey]

Hey @lmartins! Good question, thanks for posting.

I've never done dynamic imports with this library, so I'm not sure. Can you provide an example of how you're using it?

[lmartins]

Hey @estrattonbailey, thank you for looking into this.

The way I normally use the library is by passing an array of component wrappers, as such:

import ComponentA from './components/ComponentA';
import ComponentB from './components/ComponentB';

const AppComponents = {
  ComponentA,
  ComponentB
}

const app = picoapp(AppComponents);

Each component in this format returns the component instance, whereas the Webpack dynamic import returns a promise instead.

The components definition would be pretty similar:

const FooterGallery = () => import('./components/media/FooterGallery');

But what this FooterGallery holds is a promise as detailed here:
https://webpack.js.org/guides/code-splitting/#dynamic-imports

So I picoapp would need to determine the component initialisation based on whether the returned value would be a promise or a standard constructor?

[estrattonbailey]

@lmartins gotcha, makes sense. Yeah picoapp assumes each component is just a function. So in this case, it would be pretty trivial to Promise.resolve(Component) and then call the returned function.

Do you feel like taking a stab at that? I suppose it would go here.

[lmartins]

Sure! I'll give it a try.

…

Sent from my iPhone

On 11 Sep 2019, at 15:37, Eric Bailey ***@***.***> wrote: @lmartins gotcha, makes sense. Yeah picoapp assumes each component is just a function. So in this case, it would be pretty trivial to Promise.resolve(Component) and then call the returned function. Do you feel like taking a stab at that? I suppose it would go here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[tylerbrostrom]

Hey @lmartins! Hope you don’t mind, but I submitted an alternative PR ( #15 ) that effectively solves this feature request.

My use-case called for resolving an arbitrary promise (not a dynamic import). So while it’s a bit more generic, it should do the trick for you:

const FooterGallery = () => import('./components/media/FooterGallery')

// add component
app.add({
  FooterGallery: FooterGallery.then(module => module.default)
})

// bind component to DOM
app.mount()
  .then(() => console.log("FooterGallery has mounted")) // optionally run some code after `mount` resolves

[lmartins]

@bro-strummer Oh, I love what you did Tyler. Hoping that @estrattonbailey can provide some feedback on this too.

Like you, I'm loving this tiny mighty library!

[estrattonbailey]

Hey! Really appreciate both of you helping with this! Smart ideas, totally see where you're coming from. In fact, I've never actually gotten around to using dynamic imports on any project, so this is really helpful in terms of grokking what a solution will look like.

Since you're both trying to solve very similar problems, let's just discuss both PRs here!

Seems like both options do adequately solve the problem, though in slightly different ways. #13 handles modules on an individual level, whereas #15 resolves queue mounting modules as a batch. I see benefits with both, but I would think it's smart to err on the side of individual components being agnostic of how others are instantiated.

Related to that, @bro-strummer, maybe you could clarify your use case for me? Is there a reason you can't resolve data first, then call mount? Or mount, but handle dependency resolution within the component? Also, I don't think this line will work with dynamic imports, since a dynamic component would need to be wrapped in a callable to avoid being resolved immediately on page load. This would work for your example though.

I do also agree that I don't love the module.default resolution, though I've had to do similar things in the past and would agree that if #13 is the best solve, it makes sense to go that route.

I think both of these are smart solutions, but they've also got me thinking – and I apologize for not thinking more about this way back when. How much mileage could we get out of this:

1. Keep "mount" synchronous
2. Keep component agnostic of each other and individual dependencies
3. Use events to synchronize and handle cleanup
   • so might want to add mount and unmount events

// component.js
export default (node, ctx) => {
  // we don't need to return this promise here
  import('./myAsyncComponent.js').then(module => {
    // this component is basically just a normal picoapp component at this point
    const instance = module.myExportedComponent(node, ctx) // or module.default
    const unsubscribe = ctx.on('unmount', () => {
      instance.unmount() // handle cleanup as needed
      unsubscribe() // remove listener manually
    }) 
  })
}

// index.js
import component from './component.js'
const app = picoapp({ component })
app.mount()

// after route change or whatever
app.unmount()

Seems like a probably we could all spend a considerable amount of time solving and thinking about, so I apologize if I missed some minutiae within each of your solutions. Excited to hear your thoughts!

[lmartins]

@estrattonbailey I would lean towards @bro-strummer approach #15 , and would love to see the baked into the library. I'm currently patching my own version of the library just to have the functionality, and looking forward to just use the library as default again.

[tylerbrostrom]

Hey guys! Sorry to have left this cold—bit of a busy time for me. I've got a long weekend coming up and hope to put forth some consideration towards this issue then.

[lmartins]

@estrattonbailey could you please let us know if this is something you'd be willing to add to the library?

[estrattonbailey]

Hey, I'm sorry y'all. Just moved from NYC to Chicago and haven't been online much. Hoping to get around to some open source over the holidays, starting next week.

[estrattonbailey]

Hey all, sorry I'm just getting back to this. Been a busy couple of months!

Definitely still interested in this idea, but I'm wondering if the "why" is worth the added complexity – however slight it is. I might need some more context on your use cases, but what I understand so far should already be possible with picoapp.

Instead of adding code to core, do you think we could solve this with more docs and examples? Or another pattern that's opt-in, like a higher-order function?