Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MVP features #2

Open
1 of 6 tasks
ryyppy opened this issue Nov 29, 2018 · 1 comment
Open
1 of 6 tasks

MVP features #2

ryyppy opened this issue Nov 29, 2018 · 1 comment

Comments

@ryyppy
Copy link
Contributor

ryyppy commented Nov 29, 2018

  • CSS linking
  • Meta data linking (header)
  • Hook for dev-server
  • Introduce env parameter for prod / dev
  • Hook to involve Webpack for production builds
  • Integrate Fastpack for dev builds
@ryyppy
Copy link
Contributor Author

ryyppy commented Dec 1, 2018

I log some updates here as I discover things:

Bundling

I would like to keep track of components which are supposed to be bundled. This means we need to identify between static and bundled (interactive) compile units.

What should the React Compiler do for a Bundle compile Unit?

The bundle compile unit requires a unique id, given by the user. Similar as with the href utility, we could provide a function insertBundle(id), which looks in the index of the compiler and inserts the component, together with an appropriate div tag and ReactDOM mounting code.

It's basically a more first-level approach of doing Interactive components. Tell the compiler about all planned bundled components, let it do the work of bundling it and then render the static sites with all the required <script> tags and div mounting points. No html crawling needed anymore.

For the bundling process I'd like to use fastpack with subprocesses. My idea was that the bundler should solely do the JS bundling, the CSS bundling should be decoupled differently for now.

CSS

I am currently trying to build a system which will work with Functional CSS frameworks, such as Tachyons and Tailwind, so my assumption for now is globally linked CSS via layouts. The build process for the CSS could be kicked of via a different process step in the Compiler (like running a subprocess with postcss).

I think postcss should generally be the CSS engine for now... it does everything we need and collocates all the node dependencies on one tool, which is called via one subprocess. With that, the compiler would be able to know the name of the generated CSS file, so this information could be used in the compile unit processing / layout processing as well.

Later on, I was thinking of slowly migrating to OCaml native related tools, especially the Tailwind processing.

Dev Server

Fastpack is limited with the configurability of its dev-server, so I would need to contribute to fastpack and make it possible to serve a whole public directory, instead of only a single index.html file. Until then, I am happy to just use a watchman-make command and always do full builds.

For serving the files I would just use pythons SimpleHTTPServer for now... funnily enough, I think all of this will be way more responsive than anything the current Webpack 3 / 4 setup does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant