Add new `static` prop for SSR rendering

[damassi]

This PR adds a new static config prop, which when true will skip rendering of a React portal, and simply render children as they are passed into the carousel. This smooths the handshake between client / server rendering, however with the tradeoff: when static, the carousel cannot be modified at runtime (e.g., slides cannot be dynamically added or removed). For many usecases this tradeoff is acceptable. See this comment for more info.

Description of problem

While attempting to implement the carousel component, we noticed that there was a flicker when attaching to the DOM from an SSR pass:

Initially we thought that it was an issue with the underlying flickity instance on init, but digging deeper found that the problem came down to this bit of code, in react-flickity-component:

renderPortal() {    
  if (!this.carousel) return null;
  ...

During the initialization phase, the carousel instance hasn't yet been instantiated, and so null is returned from within react, leading to empty content on the page. When things init, the code proceeds and things execute correctly, albeit with a flicker.

However, when playing more with the implementation we found that the portal is unnecessary, even if the carousel is only rendered client-side. By simply returning this.props.children in the render method

  render() {
    return React.createElement(
      this.props.elementType,
      {
        className: this.props.className,
        ref: c => {
          this.carousel = c;
        },
      },
      this.props.children
    );
  }

everything attaches and initializes as it should, with the added benefit that it also works correctly during the server -> client handshake pass.

@theolampert - Wondering your thoughts? Why was renderPortal used to begin with? By removing it everything seems to work a-ok:

No flicker:

We've only been able to test this for our use-case but yeah! Any feedback would be appreciated.

(If you're curious about our SSR implementation, see here.)

[theolampert]

@damassi Thanks for the detailed PR, I need to take a closer look over this. @yaodingyd could you shed some light on the renderPortal method?

[yaodingyd]

Thanks for your contribution. Unfortunately we do have to use portal to render children. Your code works perfectly fine if your slider items are static, meaning no adding or deleting items. But if they are dynamic, it would break the component because after Flickity is initialized, the children are not rendered in the original DOM hierarchy and we have to use Portal to render them correctly.

[damassi]

@theolampert / @yaodingyd, that makes sense! Wondering, would y'all be open to adding a static configuration prop to toggle this behavior on and off?

[yaodingyd]

sounds good to me

[damassi]

Cool, i'll update this PR today.

[damassi]

Alright @theolampert - added a commit with static and updated PR description / title. Let me know if you need anything else.

[yaodingyd]

@theolampert I think I'll update readme later with the discussion of this PR.

[damassi]

Hi @theolampert - would you mind publishing this new version to NPM? Noticed the latest is still 3.2.0.

[theolampert]

@damassi done! please check 3.3.0