Extract abstract bindings #11

Activity

1. kof commented on Jun 14, 2017

   

   kof

   on Jun 14, 2017

   Last edited by kof

   Member

   More actions

   What exactly is needed to support preact and inferno out of the box? I think we all want it and if its not too special it might be ok to keep it all here in this repo.
2. kof commented on Jun 14, 2017

   

   kof

   on Jun 14, 2017

   Last edited by kof

   Member

   More actions

   Preact has preact-compat, there should be no need for all this preact-* packages. Something goes wrong if every react package willl create preact- and inferno- packages. cc @developit
3. iamstarkov commented on Jun 14, 2017

   

   iamstarkov

   on Jun 14, 2017

   Member

   More actions

   hi @rofrischmann, does abstracting mean that we will have 3 packages, like {react,preact,inferno}-theming?
4. robinweser commented on Jun 14, 2017

   

   robinweser

   on Jun 14, 2017

   Last edited by robinweser

   MemberAuthor

   More actions

   I am no expert in either Preact or Inferno, but I thought that using preact-compat is actually not the most recommended way to use Preact in general, but rather a quick production-replacement for React apps.

   Most likely it's just the different createElement import and some minor changes. Check out how we did it with Fela e.g. the createComponent-HOC:

   • Abstract Binding Factory
   • React
   • Preact

   (See how the abstract factory contains all the logic while the actual bindings simply add in the correct APIs)

   But I also see @kof's point with different packages for any React lib.

   👍React with 👍1Reacted by Jason Miller
5. iamstarkov commented on Jun 14, 2017

   

   iamstarkov

   on Jun 14, 2017

   Member

   More actions

   i see, thats neat https://github.com/rofrischmann/fela/blob/master/packages/react-fela/src/createComponent.js
6. developit commented on Jun 14, 2017

   

   developit

   on Jun 14, 2017

   Last edited by developit

   More actions

   This is a good pattern. If it's useful to you, preact now exports createElement() (same as h()). That means all the major VDOM libs support { createElement, cloneElement, Component, render } - so your factory could just accept that as an object if it's any easier. I wrote a post about the technique and how you can potentially even use a Webpack loaded to accomplish this too.

   👍React with 👍3Reacted by Oleg Isonen, Robin Raya Weser and Prithvi Raju M
7. kof commented on Oct 14, 2017

   

   kof

   on Oct 14, 2017

   Member

   More actions

   @rofrischmann can you help with this? You are already a collaborator on this project.
8. robinweser commented on Oct 14, 2017

   

   robinweser

   on Oct 14, 2017

   MemberAuthor

   More actions

   If you’re fine with 3 different packages (themig-* or *-theming where * = react/preact/inferno) I can help here, but after ReactiveConf ofc :p
   Could talk there as well
9. kof commented on Oct 14, 2017

   

   kof

   on Oct 14, 2017

   Member

   More actions

   What other choices do we have? Can it be a functional way? Like setReactLibrary() or something?
10. robinweser commented on Oct 14, 2017

    

    robinweser

    on Oct 14, 2017

    Last edited by robinweser

    MemberAuthor

    More actions

    Something like this? That would mean, we only ship the abstract factory and the library itself decides what to use?

    React

    import { createElement, Component } from 'react'
    
    const theming = themingFactory({
      createElement, 
      Component
    })
    
    // where theming ships the APIs
    const { withTheme, ThemeProvider } = theming

    Preact

    import { h, Component } from 'preact'
    
    const theming = themingFactory({
      createElement: h, 
      Component
    })
    
    // where theming ships the APIs
    const { withTheme, ThemeProvider } = theming

    (The examples are just for demonstration, might not includes every detail, but shows the idea)

    👍React with 👍1Reacted by Oleg Isonen
11. kof commented on Oct 14, 2017

    

    kof

    on Oct 14, 2017

    Last edited by kof

    Member

    More actions

    Sounds like a good solution! Way better than to produce separate packages or even repositories 😅
12. robinweser commented on Oct 14, 2017

    

    robinweser

    on Oct 14, 2017

    MemberAuthor

    More actions

    Well it really depends. If this package is only for library authors, the above example is the best solution by far, but if you want to serve direct end-user as well, separate packages for each library are much better in terms of UX/DX => "install & use".
    Thanks to tools like Lerna, managing separate packages is pretty much as if its just one.
    But I assume theming should only be used by libs anyways so we can use the factory pattern.
13. kof commented on Oct 14, 2017

    

    kof

    on Oct 14, 2017

    Last edited by kof

    Member

    More actions

    I assume we target first of all the lib authors. If we keep react by default, most regular users still don't have to do much. Also using a factory is not the end of the world.
14. developit commented on Oct 14, 2017

    

    developit

    on Oct 14, 2017

    Last edited by developit

    More actions

    Just a note: because preact exports createElement in version 7+, you can do this:

    import * as preact from 'preact'
    const theming = themingFactory(preact)
    const { withTheme, ThemeProvider } = theming

    import * as react from 'react'
    const theming = themingFactory(react)
    const { withTheme, ThemeProvider } = theming

    That'll have the added benefit of giving you access to cloneElement() in your factory.