search

bimspot / xeokit-react

Integratation of the xeokit viewer into a React application.
32 stars 22 forks source link

Headless UI & Hooks refactor #10

Open barnabasmolnar opened 4 years ago

barnabasmolnar commented 4 years ago

At a glance, the benefits of refactoring into a completely headless component include:

This approach would allow for a great deal of flexibility when creating the view/presentation layer for certain features as opposed to being locked in to a predefined layout, style, etc. The increased modularity should pave the way for a better and more productive development process. Thanks to the flexible, view agnostic design proposed here, developers would be free to apply their own styling, branding, etc.

Moving to a React Hooks based component has its own advantages as well. Exposing a custom hook could provide a lot of flexibility when it comes to working with the package. Moving to hooks would require us to specify in our docs that the React versions we support are 16.8 and up. A very reasonable compromise in my opinion.

Work has already commenced on these enhancements, see this feature branch.

An example usage of the new hooks based component might look something like this:

const HooksComponent= () => {
  const { viewerCanvasProps, takeScreenshot } = useViewer(YourLoaderPlugin, yourModel, {
    bcfViewpoint: yourBcfViewpoint,
  });

  return (
    <div>
      <canvas id="hooks-gltf" {...viewerCanvasProps} />
      <button onClick={takeScreenshot}>Take screenshot</button>
    </div>
  );
};

Note that you are no longer tied to prerendered elements for features such as taking screenshots. Nor will you have to play with refs to get around that limitation.

We simply expose several useful methods that you can get access to via using the useViewer custom hook that we provide. You just pick what you need, use the destructuring syntax to get access to it and use it wherever and in whichever way you like.

There are plans to provide convenience wrapper components as well. For instance, an <XKTViewer /> component would be merely one further layer of abstraction over of what's been shown above; instead of specifying the loader plugin yourself, it would already have the XKTLoaderPlugin plugged in by default.

You would, of course, be free to choose between using the custom hook and the wrapper components as per your needs.

A rough development roadmap:

Ideas and suggestions are always welcome.

amir-arad commented 3 years ago

yes please!