@slidebean/html-player

When the html-player deployed to NPM, we build first using this prepublishOnly script hook

Usage no npm install needed!

<script type="module">
  import slidebeanHtmlPlayer from 'https://cdn.skypack.dev/@slidebean/html-player';
</script>

README

html-player

*NOTE: all dependencies need to go into the devDependencies section of package.jon

When the html-player deployed to NPM, we build first using this prepublishOnly script hook

Deployment: html-player, html-exporter, lambda-html-exporter

html-player

We use circlici and semantic-release to publish new versions of html-player. The html-player is used in the html-exporter which is a package in the exports repo. The html-player has several dependencies (core, ui, render) that need to be updated quite often. We update those dependencies, test them using cypress we release it to npm.

html-exporter

Then we need to update html-exporter with the latest version of the html-player. The exports repo is a mono repo managed by lerna. We update the html-exporter with the latest version of html-player in the package.json file and we run yarn reinstall-deps in the root directory of the exports repo. The reinstall-deps script cleans the repo and re-installs the dependencies. We do a git commit for the latest changes and run lerna publish, usually a patch version and that gets deployed to npm. The html-exporter is used by the lambda-html-exporter which is an aws lambda function that is part of the export process.

lambda-html-exporter

We use the serverless framework for most of our lambdas (before apex/up) functions. The lambda-html-exporter is a simple wrapper for html-exporter which contains most of the "brains" for html exports. When the html-exporter has been updated, we need to update the html-exporter dependency in the lambda-html-exporter package in the lambdas repo. We deploy it using this command, npm run publish:dev and we test it on the dev stage in aws with a test downloadRequestId using the dev-start-export command.

test dev lambda-html-exporter
# deploy to dev stage
$ npm run publish:dev

# start the export process
$ dev-start-export downloadRequestId
{"message":"Step function is executing callStartExportStateMachine","retry":0}

# we go to the aws step function console
- state machine: ExportSF-dev
- we check the latest export in ExportSF-dev
- we check the makeHtml step (lambda-html-exporter) input
- we get `exportUrl` in the input info
- we get the export in a browser or we use curl or wget
- we check the export, if the export is fine, with no error, we deploy to production

test prod lambda-html-exporter
# deploy to dev stage
npm run publish:prod

# start the export process
$ start-export downloadRequestId
  or
export a presention in the app, https://app.slidebean.com
{"message":"Step function is executing callStartExportStateMachine","retry":0}

# we go to the aws step function console
- state machine: ExportSF-prod
- we check the latest export in ExportSF-prod
- or we check it in the app, or we get it on iron-throne

How it works

The the html-player is a small angular app that has slidebean dependencies; the main dependency is @slidebean/render. The html-player expects an html file that contains the presentation data in a variable called __sb__. It uses @slidebean/core to instantiate the objects for the json data to be passed to the render component.

Example html file:

<script>
  window.__sb__ = {
    presentation: {"title":"icons","owner":
   {"__type":"Pointer","className":"_User","objectId":"PE9xMpcCYG"},
    ...
</script>

Updating @slidebean/render

If render is updated, the html-player needs rebuilt and published to npm so so that html-exporter can also be updated.

# get the latest
npm install --save @slidebean/render@latest

# rebuild the assets
npm run _build

# bump version, update to github, etc...

# publish
npm publish

Hiding assets

By default angular produces a ./dist directory with the index.html and many assets (fonts, js, fav icons. etc...). This is a problem for the html-exports if we want to produce a "clean" export for users. The way that we get around this is by changing the paths of assets in the html file. This is done in the build step. Below is the structure of an html folder.

HTML Folder

├── assets
│   ├── favicon.ico
│   ├── fonts
│   │   └── ...
│   ├── img
│   │   └── ...
│   ├── js
│   │   └── ...
│   └── render
│       └── ...
└── presentation.html

The build does the following:

  • build the angular app
  • move favicon to assets folder
  • make img directory
  • make a .gitkeep file to make sure the directory is created
  • make js directory
  • move *.bundle.js files into assets/js
  • remove bundle map files
  • remove unneeded fontawesome files
  • update the fontawesomoe paths in the styles.bundle.js
  • copy the test index.html for testing.
ng build --output-hashing=none && \
  mv dist/favicon.ico dist/assets/ && \
  mkdir dist/assets/img && \
  touch dist/assets/img/.gitkeep && \
  mkdir dist/assets/js && \
  mv dist/*.bundle.js dist/assets/js/ && \
  rm dist/*.bundle.js.map && \
  rm dist/fontawesome-* && \
  node update-font-path && \
  cp index.html dist/

development

# watch and compile and changes
npm run dev

Building

Run npm run build to build the project. The build artifacts will be stored in the dist/ directory. Use the -prod flag for a production build.