In preparation for server-side rendering, we need some mechanism to generate components that don't depend on dart:html. This will likely be a build option, but we can make the transition easier by already using universal_html under the hood. universal_html is an alias for dart:html when compiling to the web, but defines compatible APIs for use on the Dart VM too.
With universal_html, we can also make it easier to debug and test zap component logic outside of a browser. It would be interesting to know how much currently breaks when using universal_html, so a investigation would be really helpful.
We can probably replace dart:html imports in the zap package.
In the zap_dev generator package, we can use the import rewriting mechanism to rewrite dart:html imports in <script> tags with universal html imports.
Some things that would be interesting to know:
How many of the current zap components (in this repo) break when using universal_html? Will be a lot of effort to fix them?
Can we reliably run tests for some components in the Dart VM when using universal_html?
In preparation for server-side rendering, we need some mechanism to generate components that don't depend on
dart:html
. This will likely be a build option, but we can make the transition easier by already usinguniversal_html
under the hood.universal_html
is an alias fordart:html
when compiling to the web, but defines compatible APIs for use on the Dart VM too.With
universal_html
, we can also make it easier to debug and test zap component logic outside of a browser. It would be interesting to know how much currently breaks when usinguniversal_html
, so a investigation would be really helpful.dart:html
imports in thezap
package.zap_dev
generator package, we can use the import rewriting mechanism to rewritedart:html
imports in<script>
tags with universal html imports.Some things that would be interesting to know:
universal_html
? Will be a lot of effort to fix them?universal_html
?