linkedin / linkedin/css-blocks
Parallelization
- Dominant language
- TypeScript
- Stars
- 6.3k
- Forks
- 154
- PR merge metrics
- No merged PRs in 30d
Description
I'm going to break down my current understanding of how CSS blocks works (I think as long as I'm close enough it will work for explanation purposes)
- Find all the CSS Blocks files (recursively)
- Parse out all the selectors for the CSS Blocks files
- Create interfaces for every CSS Blocks file
- Transform CSS Blocks files(?)
- Find all the JS/HBS files that use CSS Blocks
- Parse out all the usages of CSS Blocks
- Replace them with the appropriate selectors
- Continue transforming JS/HBS files by whatever tool CSS Blocks is running inside
The problem with this design is that in expects to happen in a very specific order and to have all the information it needs before continuing. This means that you cannot parallelize the transformation of CSS Blocks files and JS/HBS files that use CSS Blocks.
In a large app where every component uses CSS Blocks, this will have a really noticeable performance impact, you'll be blocking the transformation of hundreds if not thousands of files on an effectively synchronous process.
So I would like to revisit the design of CSS Blocks to see if there are things that we can do so that JS/HBS files and CSS files can be transformed in parallel, even if it means we have to revisit JS/HBS files after the CSS is done.
- Transform CSS Blocks/JS/HBS in parallel
- CSS Blocks
- Parse out selectors
- Create interfaces
- Transform(?)
- JS/HBS
- Replace usages of CSS Blocks with "references" that can be optimized out later
- Transform
- Optimizations after everything has been transformed
- Validate CSS Blocks interfaces in JS/HBS
- Optimize away references in JS/HBS with appropriate selectors
These references could be just strings that CSS Blocks is able to identify:
```js
"css-blocks-ref:path/to/button.css:size(small)"
```
Or maybe something more complex than that. The point is that you could come back later on and map it to something that was calculated in parallel elsewhere.
/cc @devongovett
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by mapping the current CSS Blocks transformation stages described in the issue, then determine how CSS and JS/HBS transformations could run in parallel. Done means interfaces and usages are validated after transformation and references are optimized to the appropriate selectors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, handlebars, javascript, typescript
- Domain
- build-system, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100