-
-
Notifications
You must be signed in to change notification settings - Fork 469
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
feat: support 'before' insertions (options.insertAt
)
#253
Changes from 1 commit
4d8e641
0bee7a6
03c8170
5618dd2
0caab23
55d2e41
934bbaf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -72,6 +72,8 @@ module.exports = function(list, options) { | |
// By default, add <style> tags to the bottom of the target | ||
if (!options.insertAt) options.insertAt = "bottom"; | ||
|
||
if (options.insertAt === "before" && !options.insertBefore) throw new Error("Must specify selector in `insertBefore` when specifying `insertAt = 'before'`"); | ||
|
||
var styles = listToStyles(list, options); | ||
|
||
addStylesToDom(styles, options); | ||
|
@@ -170,6 +172,9 @@ function insertStyleElement (options, style) { | |
stylesInsertedAtTop.push(style); | ||
} else if (options.insertAt === "bottom") { | ||
target.appendChild(style); | ||
} else if (options.insertAt === "before") { | ||
var nextSibling = getElement(options.insertInto + " " + options.insertBefore); | ||
target.insertBefore(style, nextSibling); | ||
} else { | ||
throw new Error("Invalid value for parameter 'insertAt'. Must be 'top' or 'bottom'."); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Error message should include valid option 'before':
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will this throw in the browser console or during build time? If the latter this.emitError("Style Loader\n\n Invalid value for parameter 'insertAt' ('options.insertAt') found.\n Must be 'top' or 'bottom'.\n (https://github.com/webpack-contrib/style-loader#insertat)\n") else throw new Error("[Style Loader]\n\n Invalid value for parameter 'insertAt' ('options.insertAt') found.\n Must be 'top' or 'bottom'.\n (https://github.com/webpack-contrib/style-loader#insertat)\n") |
||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree with an extra top level option depending on other one. Possible to pass the an
{Object}
toinsertAt
instead{ type: 'before', $: '#id' }
($
maybe better namedselector
) [Needs discussion]There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I wasn't completely sure the best way to approach this. The logic for
insertBefore
could also be triggered without requiring anything special ininsertAt
. In other words, ifinsertBefore
has a non-empty string that behavior pre-empts the normal insertion logic triggered byinsertAt
.I steered away from that because it seemed potentially confusing to have
insertBefore
pre-empt and essentially override the behavior ofinsertAt
.I'm also fine with making
insertAt
an object, but that becomes a breaking change. If you think that's best I can go with it, but it seems kind of heavy-handed for a small feature.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see how it can be done in a backwards-compatible fashion. Pushed an implementation. Another option for the Object interface is
{ before: '#id'}
, which lets us avoid the ambiguous-soundingtype
key and avoid choosing between$
andselector
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah an
{Object}
isn't optimal in terms oftype
consistency either, but inter option dependence isn't aswell, the interface you suggested is much better though :)