Hacker News Reader

Comment by k__ | Hacker News Reader

Didn't have a good experience with this kind of React wrappers, I used a Leaflet wrapper for a few years.

They always lack behind and try to force the React lifecycle and composition onto the library. Often this leads to leaking abstractions, which get uglier and uglier with time. Updating is also not a charm.

I stopped using them and simply build one component as facade, then use props as interfaces to the lib while letting the lib do its thing the way it wants behind that component.

View on HN

Not to discount your experience, which is pretty consistent with my own, but what you've just described is writing your own wrapper component.

I think there's something to be said for doing it yourself, particularly when the available options make you have to care about their internals anyway. But perhaps some of that effort might be put towards making a better open-source wrapper.

I've worked a little bit with libraries like this (react-mapbox-gl) and I think the point GP is making is more like this:

    <3P.Wrapper>
      <3P.Foo>
        <3P.Bar
          subcomponent={props}
        />
      </3P.Foo>
      { someCondition ?
        <3P.Quux
          onCrunch={doQuack}{
        />
      }
    </3P.Wrapper>

where mounting and unmounting those child components interacts with the wrapped API. Contrast that with

    <3P.BasicWrapper
      useFoo
      useBar
      useQuux={someCondition}
      onQuuxCrunch={doQuack}
    />

which is less suitable for generic use, but easy enough to write (and modify later) that you probably don't need a highly-generic wrapper.

There is a difference between creating one component as entry to the lib and using React for the whole state management.

I've had the same experience. Especially if you get into using more and more niche packages (plugins for Leaflet), it can get ugly pretty fast.

And if you need many customizations

Reply on news.ycombinator.com