0.1.0 • Published 4 years ago

pligrate v0.1.0

Weekly downloads
-
License
ISC
Repository
-
Last release
4 years ago

Running Prettier

Prettier should be run after a successful migration

$ prettier --print-width 120 --single-quote --trailing-comma es5 --write components/**/**/*.jsx

TODO

High

  • publish this
  • make this into a gulp plugin?
  • have the script create a manifest instead of logging out what files need to be fixed
  • come up with a way to prevent files from being overwritten
  • migrating can be a little flaky at times
  • deeply nested components are not being written
  • finish prettier ignore list
  • handle partials with attributes
  • Improve handling ignored files, ie files with markdown

Medium

  • component import paths may not be correct
  • improve handling props (where does data come from, how should it be passed to components)
  • think about productizing this and writing a blog post
  • improve this to migrate only one file at a time or entire directories..

Low

  • prefer .jsx over .js
  • shorthand fragments
  • prefer named components over anon and export after the definition and should set the component display name
  • file naming should be pascal case
  • finish compileIfEqual compiler
  • write tests
  • Handle #carouselIterator
  • handle with blocks
  • better fix for inline if
  • inline partials
  • handle partials with children

Known Issues

Props

The compiler is unaware of the shape of our yaml files, thus, it makes a lot of assumptions about what data to render in components. Additionally, when the compiler encounters Panini helpers it begins to breakdown even further as it does not have any knowledge of data is used throughout the website.

For example, in src/partials/collage.html Panini refers to the iterable as this which does not transpile well to javascript. An example is illustrated below:

src/partials/collage.html

  <div class="collage">
    {{#each this.collage}}
      <div class="collage__item collage__item--{{grid-item}}">

        {{#ifequal this.item-type 'modal'}}
          <div class="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img class="lazy" data-src="{{img-url}}" alt="{{alt-text}}">
          </div>
        {{/ifequal}}

        <!-- all other code omitted -->
    {{/each}}
</div>

is compiled to:

src/components/collage.js

<div className="collage">
    {props.collage.map((item, i) => <React.Fragment key={i}>      <div className={"collage__item collage__item--" + item['grid-item']}>

        {this['item-type'] === 'modal' && ( 
          <div className="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img className="lazy" data-src={item['img-url']} alt={item['alt-text']} />
          </div>
         )}
    )}
</div>

Manual intervention and cross-referencing the yaml passed to this file is required to correct bugs such as this. Assuming that props is passed as <Collage collage={props.impact} />, the solution would be:

<div className="collage">
    {props.collage.map((item, i) => <React.Fragment key={i}>      <div className={"collage__item collage__item--" + item['grid-item']}>

        {item['item-type'] === 'modal' && ( 
          <div className="collage__image collage__image--ix modal-trigger" data-open="collage-modal">
            <img className="lazy" data-src={item['img-url']} alt={item['alt-text']} />
          </div>
         )}
    )}
</div>

Inline If

When transpiling inline if conditions such as:

<div class="static-data-table {{if no-top-padding 'static-data-table--no-top-padding'}}">

The result ends up like:

<div className="static-data-table { props['no-top-padding'] ? 'static-data-table--no-top-padding' : null}">

and will need manual intervention:

<div className={`static-data-table ${props['no-top-padding'] ? 'static-data-table--no-top-padding' : null}`>