Allow dynamically loaded example files

[acelaya]

This PR adds support to individual examples files that can be used in the pattern library docs both to generate actual working examples that are part of the bundle, while at the same time we load them as un-processed plain text that can be inlined as code snippets.

Those files are type-checked, linted and formatted, ensuring they are always up to date with the actual source code and they follow our standard rules.

In order to achieve this, this PR adds a new examples folder inside src/pattern-library. Files in this folder are statically exposed via express/nginx, so that we can do a fetch('/examples/filename.tsx') and load them as plain text.

At the same time, we can dynamically import those files in order to use the actual source code, with import('/examples/filename.tsx').

This PR extends the Library.Demo component to accept an exampleFile prop, <Library.Demo exampleFile="some-file" />, which transparently does both things internally by loading the contents of the referenced example file.

Additionally, the existing <Library.Code /> component has been enhanced to also allow an exampleFile prop instead of content, in order to load the source code from an external file.

This PR also adds a couple examples as a proof of concept of this new functionality.

TODO

• Consider caching/memoizing the content of examples that have already been fetched. I finally refactored a bit the logic, so that the file is loaded when Demo renders, not every time the tab changes. That way all files are only fetched once when the page loads.
• Document limitations of the approach (extension must be .tsx, no nested dirs supported, recommendation to prefix file names, requirement of a default export, etc.)

Considerations

Some alternative approach to get the static example file content could go into using some babel or rollup plugin that captures the use of fs.readFileSync or similar. I found a couple but they were mostly unmaintained and outdated, and I saw some reported issues regarding incompatibilities with modern practices, so I decided to go the fetch way instead.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (2d2cffd) to head (ad5b384).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1558   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           62        62           
  Lines         1037      1037           
  Branches       394       394           
=========================================
  Hits          1037      1037           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[robertknight]

The basic idea of having the example in an external .tsx file which is then imported as script to render as a live demo, and also imported as text to render as syntax highlighted code, makes sense. It will probably be useful to keep the ability to have "inline" demos where the code is generated from the component, for simple use cases.

[robertknight]

I took another pass over this. One thing I notice is that the code passes source code to jsxToHTML and that happens to work, but the function is clearly expecting JSX expressions. It would make sense to add a separate function which takes in TypeScript source and returns the highlighted code. jsxToHTML can then call that internally.

[robertknight]

I think this can be merged, but I noted a few improvements for consideration:

• I noticed some visual flicker when switching between the demo and code tabs in Safari and Chrome. I noted a way to fix this using display: 'none', but it would mean creating DOM nodes for the code even if the user hasn't looked at them, unless you add more code to lazily render the source.
• I suggested in the useEffect that it should only fetch the data and set state, but do the actual rendering synchronously as part of the render.
• highlightCode should have a note about its suitability for use with dangerouslySetInnerHTML