Add replaceNode switch #141

Merged
BehindTheMath merged 3 commits from feature/add-replace-node-switch into master 2018-03-20 09:52:56 -05:00
BehindTheMath commented 2018-03-15 20:12:39 -05:00 (Migrated from github.com)

This adds a new default switch which is functionally the same as the outerHTML switch, but uses Node.replaceChild() instead of outerHTML, so it doesn't require switchElementsAlt.

This adds a new default switch which is functionally the same as the `outerHTML` switch, but uses `Node.replaceChild()` instead of `outerHTML`, so it doesn't require `switchElementsAlt`.
BehindTheMath commented 2018-03-15 20:13:19 -05:00 (Migrated from github.com)

@robinnorth Should we consider using this as the default switch instead of outerHTML?

@robinnorth Should we consider using this as the default switch instead of `outerHTML`?
robinnorth commented 2018-03-16 08:34:51 -05:00 (Migrated from github.com)

Would be good to know if there's any performance difference between the two switches (and any browser-specific known issues that need considering, not that I can think of any) before making it the new default. Making it the new default would also be a breaking change, so you'd have to do that in 0.3.0 (still think that should be 1.0.0!).

Would be good to know if there's any performance difference between the two switches (and any browser-specific known issues that need considering, not that I can think of any) before making it the new default. Making it the new default would also be a breaking change, so you'd have to do that in 0.3.0 (still think that should be 1.0.0!).
BehindTheMath commented 2018-03-16 10:11:54 -05:00 (Migrated from github.com)

Would be good to know if there's any performance difference between the two switches

Based on this jsperf test, replaceChild is 3x as fast as innerHTML. Regardless, I don't think the practical difference will be more than a few milliseconds, since I doubt anyone is replacing more than a few elements.

(and any browser-specific known issues that need considering, not that I can think of any)

According to this (referenced by Caniuse), parentNode and replaceChild are supported properly by all browsers.

Making it the new default would also be a breaking change, so you'd have to do that in 0.3.0 (still think that should be 1.0.0!).

Absolutely. I would make a new PR for that after v0.2.6 is finished.

>Would be good to know if there's any performance difference between the two switches Based on [this jsperf test](https://jsperf.com/replacechild-vs-outerhtml-efficiency), `replaceChild` is 3x as fast as `innerHTML`. Regardless, I don't think the practical difference will be more than a few milliseconds, since I doubt anyone is replacing more than a few elements. > (and any browser-specific known issues that need considering, not that I can think of any) According to [this](https://quirksmode.org/dom/core/) (referenced by [Caniuse](https://www.caniuse.com/#search=replacechild)), `parentNode` and `replaceChild` are supported properly by all browsers. >Making it the new default would also be a breaking change, so you'd have to do that in 0.3.0 (still think that should be 1.0.0!). Absolutely. I would make a new PR for that after v0.2.6 is finished.
BehindTheMath commented 2018-03-17 23:21:12 -05:00 (Migrated from github.com)

I rebased on master and force-pushed to be able to update the Typescript definitions.

I rebased on master and force-pushed to be able to update the Typescript definitions.
robinnorth commented 2018-03-20 07:00:26 -05:00 (Migrated from github.com)

Cool, all sounds good to me.

Cool, all sounds good to me.
robinnorth (Migrated from github.com) approved these changes 2018-03-20 07:00:39 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: iLoveElysia/pjax#141