linkedin / css-blocks

High performance, maintainable stylesheets.
http://css-blocks.com/
BSD 2-Clause "Simplified" License
6.33k stars 152 forks source link

Synchronous Block Parsing Support #502

Closed chriseppstein closed 3 years ago

chriseppstein commented 3 years ago

In order to properly support ember-cli integration, we need to be able to parse blocks synchronously, because all of the plugin and integration code surrounding template processing is done synchronously.

Block Factories

This change introduces a new block factory class named BlockFactorySync which implements the same API as BlockFactory but all of the methods are synchronous instead.

In order to minimize duplication, the two factories share a common base class named BlockFactoryBase.

Block Parser

I didn't split block parser up into two classes because for the most part, block parsing is actually synchronous. The only parts of of block parsing that was async was dealing with the importing/exporting of other blocks via the factory. So in this class, I took the approach of building xxxSync methods which implement a synchronous version of the corresponding async method.

It is legal to invoke the async methods of block parser if it is constructed with a synchronous block factory, however, if the block parser is constructed with an async block factory, there will be an error raised if any xxxSync method of block parser is invoked.

Importing

In order to support synchronous loading, importers must now implement an additional method named importSync. All the importers in this monorepo have been updated accordingly.

Preprocessing

In order to support synchronous loading, there is a new option that can be passed to CSS Blocks called preprocessorsSync. If a block is being loaded synchronously, this option is used to get access to preprocessing that will work in sync mode.

The eyeglass integration was updated to support synchronous preprocessing, addons and libraries that are consuming the @css-blocks/eyeglass library to expose a preprocessing adaptor won't need to change other than to upgrade to the latest version of this library.

Applications that are using @css-blocks/eyeglass to consume libraries will need to make a small change to their integration code that sets up the preprocessing options passed to css blocks. Those changes can be seen in the README of that package.