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

Jump to bottom

should HTML Imports support package: scheme? #12867

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

should HTML Imports support package: scheme? #12867

jmesserly opened this issue Aug 28, 2013 · 19 comments
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue P1 A high priority bug; for example, a single project is unusable or has many test failures type-enhancement A request for a change that isn't a bug
Milestone
1.1

Comments

@jmesserly
Copy link

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?
@jmesserly
Copy link
Author

Marked this as blocking #11034.

@jmesserly
Copy link
Author

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.

@sethladd
Copy link
Contributor

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

@jmesserly
Copy link
Author

@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

@dgrove
Copy link
Contributor

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.

@munificent
Copy link
Member

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.

@sigmundch
Copy link
Member

Issue #13684 has been merged into this issue.

@jmesserly
Copy link
Author

@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?

@jmesserly
Copy link
Author

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

@munificent
Copy link
Member

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?

@jmesserly
Copy link
Author

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

@sigmundch
Copy link
Member

Added this to the M8 milestone.

@sigmundch
Copy link
Member

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

@DartBot
Copy link

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.

@DartBot
Copy link

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?

@sigmundch
Copy link
Member

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">...

@DartBot
Copy link

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?

@sigmundch
Copy link
Member

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

@jmesserly
Copy link
Author

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

Added WontFix label.

@jmesserly jmesserly added Type-Enhancement P1 A high priority bug; for example, a single project is unusable or has many test failures labels Nov 14, 2013
@jmesserly jmesserly added this to the 1.1 milestone Nov 14, 2013
@sigmundch sigmundch mentioned this issue Jun 3, 2015
Closed
@DartBot DartBot mentioned this issue Jun 3, 2015
Closed
@kevmoo kevmoo added closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug and removed resolution-wont_fix labels Mar 1, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue P1 A high priority bug; for example, a single project is unusable or has many test failures type-enhancement A request for a change that isn't a bug
Projects
None yet
Milestone
1.1
Development

No branches or pull requests
7 participants
@sethladd @kevmoo @munificent @jmesserly @sigmundch @dgrove @DartBot