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

Already on GitHub? Sign in to your account

should HTML Imports support package: scheme? #12867

Closed
jmesserly opened this Issue Aug 28, 2013 · 19 comments

Comments

Projects
None yet
7 participants
Member

jmesserly commented Aug 28, 2013

It seems like this feature would be useful for the exact same reason it is useful in Dart code--so packages can reuse widgets and be bundled into a package manager. On the other hand, I can't imagine native support for this in the browser. What should we do?

Member

jmesserly commented Aug 28, 2013

Marked this as blocking #11034.

Member

jmesserly commented Aug 28, 2013

hmm, we discussed this, while it's not 100% clear here are a few data points:

* at deploy time, none of this matters because we'll deliver the app as flattened HTML+JS/Dart files

* at development time, we can handle this in HTML Imports boot.js

another data point: Web UI used to support this, it seemed natural enough.

Member

sethladd commented Aug 29, 2013

We have reuse today, with <link rel="import" href="packages/foo/components/foo.html"> What problems do you foresee with this scheme?

Member

jmesserly commented Aug 29, 2013

@seth - It doesn't canonicalize files properly leading to bugs like the 11034.

Also it depends on symlinks on disk, which the Pub folks don't like.

I'm actually not sure it even works if you have one component package depend on another one since Pub doesn't create symlinks inside packages lib folder

Owner

dgrove commented Oct 2, 2013

Dropping to High, which still means that we need to solve for M8.


Removed Priority-Critical label.
Added Priority-High label.

Member

munificent commented Oct 3, 2013

Also it depends on symlinks on disk, which the Pub folks don't like.

Once the new dev server is in place, if we can presume users are going through that, then the symlink issue here is resolved. Pub serve handles "packages/" URLs directly without looking for them on the file system.

Member

sigmundch commented Oct 3, 2013

Issue #13684 has been merged into this issue.

Member

jmesserly commented Oct 3, 2013

@bob -- interesting. what does that mean for canonicalization? is the idea that Pub will handle both:

packages/foo/packages/bar/bar.html
packages/bar/bar.html

... and issue a redirect to the browser, so it knows they're the same file?

Member

jmesserly commented Oct 3, 2013

(for the record, I'm strongly in favor of avoiding "package:" in HTML if possible... having a new URI scheme in HTML is tricky)

Member

munificent commented Oct 3, 2013

Ugh, canonicalization.

No, we don't currently do anything special to handle that. With Dart code, I believe we don't need to (though I could be wrong). If the code is using "package:" everywhere, the resolved URLs should be effectively pre-canonicalized.

References to stuff in non-Dart code that's using "packages/" explicitly is harder. But, then, does canonicalization matter if the thing being referenced isn't a Dart file?

Member

jmesserly commented Oct 3, 2013

yeah, HTML Imports do canonicalization for similar reasons -- to avoid loading the same HTML twice.

Member

sigmundch commented Oct 7, 2013

Added this to the M8 milestone.

Member

sigmundch commented Oct 9, 2013

Removed this from the M8 milestone.
Added this to the Later milestone.

Member

DartBot commented Nov 7, 2013

This comment was originally written by @zoechi


Any progress?

dart2js doesn't work for elements which import elements from other packages as pointed out in 13684.
We would really like to publish demo pages for the polymer_elements/polymer_ui_elements we are porting.

I have also some troubles with those elements in Dartium which may be caused by the import workaround.

This is the biggest obstacle for my work currently.

Member

DartBot commented Nov 7, 2013

This comment was originally written by @zoechi


may https://code.google.com/p/dart/issues/detail?id=12400 be related to this too?

Member

sigmundch commented Nov 7, 2013

We don't have a solution yet. The best workaround I have currently is to follow this convention:
 - in web/ use "packages/name/element.html"
 - in lib/ use "../../packages/name/element.html" (add more ../ if you are deeper in the tree)

So when you join the paths, packages get resolved correctly. Using your example from the other bug:

dartclient - web/index.html:
<head><link rel="import" href="packages/elements_a/my_login.html">

elements_a - lib/my_login.html
<link rel="import" href="../../package/elements_b/bs_dropdown.html">
<polymer-element name="bwu-login">...

Member

DartBot commented Nov 14, 2013

This comment was originally written by @zoechi


This still doesn't work.

It works somehow in Dart (but I guess some other problems I face are caused by this - especially with elements extending others - have to investigate further)
and it doesn't work with dart2js.

pub build output:
Build error:
Transform ImportInliner on polymer_elements_examples|web/polymer_anchor_point.html threw error: Transform ImportInliner on polymer_elements_examples|web/polymer_anchor_point.html tried to load missing input polymer_ui_elements|../packages/polymer_elements/polymer_flex_layout/polymer_flex_layout.html.
null

When I change the path so that it works with pub build (remove ../../) it doesn't with Dart.
The path necessary for pub build seems the right way to go.
Why can't Dart do what JS can?

Member

sigmundch commented Nov 14, 2013

Removed this from the Later milestone.
Added this to the M9 milestone.

Member

jmesserly commented Nov 14, 2013

We'll need to find another solution :| "package:" is not supported by HTML.


Added WontFix label.

@jmesserly jmesserly added this to the 1.1 milestone Nov 14, 2013

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment