We’ve released the major version 4 of Naver’s open source carousel library Flicking.
This major update has been running Flicking for the past two years and aims to solve problems that Flicking had but was difficult to solve and further develop.
These are the key changes in Flicking v4.

New Flicking preserves the user’s UI as it is

One of the directions that Flicking has from v3 is to keep the user-created UI intact. A large number of carousel libraries have the behavior of resizing internal panel elements, often providing a default option for “how many panels to display on the screen”, and using separate options to keep the user’s UI intact.

A demonstration of the slick to set the number of panels (slides) to show at a time

On the other hand, Flicking uses the user’s UI as the top priority. All other UI-related settings are based on the user’s CSS, as long as they include the basic DOM structure and CSS for implementing the Carousel UI. For example, the user can easily change the size of each panel by using the “width” of the CSS or adjust the spacing between panels by using the “margin” of the CSS.

<Flicking>
  <!-- 100px panel, 10px gap with next panel -->
  <div style="width: 100px; margin-right: 10px;"></div>  <!-- Panel with 20% size compared to parent element -->
  <div style="width: 20%"></div>
</Flicking>

Although Flicking v3 also supported the above features, it was not possible to adjust the spacing between panels or implement natural animation through width transitions because the “position: absolute” property was set on the panel. Also, due to these properties, the user’s UI was often broken unless the panel height was explicitly specified.

Warning about DOM structures in Flicking v3

Instead of “position: absolute”, Flicking v4 uses Flexbox-based CSS to place panel elements. Through this, we solved the problems previously described in Flicking v3 so that users can customize the UI more easily. It also provides separate CSSs based on “display: inline-box” for pages that need to support IE9.

Support for Server-Side Rendering (SSR) via separate CSS files

Although Flicking v3 also allows the use of Server-Side Rendering in environments such as Nuxt and Next, Flicking v3 uses a “position: absolute” based panel placement method, which can cause panels to stack vertically before hydration. Therefore, in Flicking v3, the user had to create a separate CSS to apply before rendering.

The user had to add the above CSS himself.

Flicking v4 provides CSS files in addition to component js files. In addition to being able to maintain UI before and after hydration in the SSR environment, markup and script developers can share the same UI before and after mounting the component script.

More & Easier customization

As we distributed Flicking v4, we also updated the documentation and demo page. Because the existing Flicking v3 provided API documents only for Flicking and Panel, detailed customization was difficult. In addition, despite supporting frameworks such as React, Angular, and Vue, there were no related tutorials, which led to constant inquiries about how to use them.

API document page for Flicking v3

Flicking v4 has improved this by adding tutorials to check how to use each framework and including API documents of internal components that can be utilized to create custom plug-ins or UXs.