b8r niceties

b8r-component-0.0.1.vsix is a tiny vscode extension that causes css and html embedded in Javascript template strings to be correctly highlighted, and also provides a convenient component boilerplate.

So, I am once again able to use b8r for my day-job, which means I get to smooth rough edges for production (some of which I handled at Airtime, but that was pre import and nowhere near as slick as I’ve made things now).

One of the things I’m constantly thinking about is how I’m going to onboard new engineers once we start hiring them, and how to not give them any nasty surprises. My goal is for a solid engineer to be able to build useful components within their first day, and have a broad-strokes understanding of the entire system within a week.

At Airtime, the engineers I hired were productive the day they joined, and our CTO was able to fix a bug in the “proof of concept” client I gave him which convinced the company to adopt b8r. A lot of this was due to the very well-documented, and reliable, microservice architecture the backend folks had put together, at Parallel Learning I am responsible for everything.

One of my favorite new(ish) features of b8r is “pure javascript” components, because they eliminate the taint of eval without even requiring a build process and they address all the failings of the original HTML-based components. But the HTML components did have one virtue, which is that most editors would recognize blocks of Javascript and CSS and syntax-hilite them correctly. (See above.)

Here’s a link to the extension (I can’t be bothered jumping through the hoops necessary to publish this thing right now).

The repo is here. The hardest part of the exercise was figuring out that the language id for css was styles.css (and not, for example text.css or language.css).

Other Cool Stuff

I’m rolling up the base application code using rollupjs, formatting using standardjs, and keeping components dynamically loaded and cache-friendly. I’ve implemented my own, tiny, jest-like test library (es6-test.mjs) that supports es6 modules properly (although, since it uses nodejs the test-runner is, ironically, written using require.

Here are some tests from es6-test.test.mjs:

test('expect.toEqual', () => {
  expect(false).toEqual(false)
  expect(false).not.toEqual(true)
  expect({ foo: 17 }).toEqual({ foo: 17 })
  expect({ foo: 17 }).not.toEqual({ foo: 0 })
  expect({ foo: 17 }).not.toEqual({ foo: 17, bar: false })
  expect({ foo: 17, bar: 'baz' }).not.toEqual({ foo: 0 })
})

test('goldenTest', async () => {
  await goldenTest('localhost', 'http://localhost:8080', { waitUntil: 'networkidle0' })
})

As you can see, I’ve gone to some lengths to make it look a lot like jest, until you want to write async tests or goldens, and then it’s much, much nicer.

One neat thing I did with all this is automatic golden-testing for all components (since, as you can see above, it’s so very difficult to write those tests by hand). There’s a test script in the components directory that finds all the components and then renders them using puppeteer; you can embed test-specific code in comments within the files, e.g. to populate a component with mock data). So, with very little effort a component can be integration-tested.

E.g. here’s the test comment-block for my (user) list-component… (As an aside, I don’t think it would be hard to add support syntax-coloring these test code blocks to my VSCode extension.)

/* test
const listPromise = b8r.json('/mocks/users.json')
const tablePromise = import('../node_modules/@tonioloewald/b8r/components/data-table.component.js')
Promise.all([tablePromise, listPromise]).then(([module, list]) => {
  b8r.makeComponent('data-table', module.default)
  document.querySelector('.list-component').data.list = list
})
*/

Also, the current debug-loop is is non-existent (save the file, reload). Assuming golden tests don’t fail, you can lint (html, css, js), build, and deploy to “production” in a few minutes.

There’s more I want to do. Next, I want to create a simple watcher that lints and tests files as soon as they’re changed (there’s no compile cycle) and injects a small status panel into pages served in the test environment that shows problems immediately (and in particular, allows you to see golden diffs, and approve changes) and can also allow instant reload (even though I’m probably going to leave it switched off). It also seems like a good excuse to play with a simple socket server.