Code size when using custom preview

[sr258]

I wonder whether using the custom previews by importing import { preview } from "@reactpreview/config"; will increase the code size when using Webpack. Or is everything that PreviewJS adds removed by treeshaking?

[fwouts]

Hey @sr258, that's an excellent question.

In React Preview, preview is implemented as a no-op function (see https://reactpreview.com/docs/features/custom-previews), so as long as webpack is configured to run tree shaking, that code shouldn't end up in your production bundle, unless you do something like:

preview(MyComponent, {
  foo: somethingWithSideEffects()
});

In this particular case, webpack would be right not to eliminate the side effects (as would effectively modify application behaviour), and it would indeed have an impact on your bundle.

In Preview.js (which will soon replace React Preview), setupPreviews is also implemented as a no-op function, but it allows you to pass a function that returns props, instead of directly a props object. Since that function is never invoked, webpack should be able to discard it without worrying about changing application behaviour.

To confirm this, you could build your application with and without a custom preview defined, and compare the generated bundles.

Let me know if this makes sense!

[sr258]

It does make sense. I've used the webpack-remove-code-blocks package to mark the previews as removable with React Preview. Is Preview.js already production-ready?

[fwouts]

Yes it is, although that doesn't guarantee the absence of bugs of course :) In fact I've just released v1.1.0 which brings it pretty much to parity with React Preview, aside from a couple of smaller features. I'll deprecate React Preview officially in a few days.

I didn't know about the webpack-remove-code-blocks package, that's great! I'll have to see if it's possible to add a test to Preview.js that programmatically checks that the output is the same with or without the setupPreviews() call. No promises on timelines though!