-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Feature/multiple portals in one target #80
Feature/multiple portals in one target #80
Conversation
…om sometimes duplicating elements.
Hey @eschalks Many thanks for this! As you can see in #76 I tried another approach, but that was a dead end, so this is a welcome starting point, looks good in first sight. I'll take a closer look hopefully tomorrow night. I was thinking about doing something similar but was hesitant to use an array because I do't like looking up stuff in arrays for performance reasons - but seeing this I think, this portal concept isn't meant to be used with hundeds of sources all sending to the same destination, so that should be fine. I'll report back ASAP, then you can add some more tests. If I find anything off, I will push directly to your branch, hope that's ok. |
src/components/wormhole.js
Outdated
|
||
const currentIndex = this.getTransportIndex(transport) | ||
if (currentIndex === -1) { | ||
this.transports[to].push(transport) |
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 think we should maybe use .shift
instead, so that for Targets with multiple=false
, the latest source is displayed at all times.
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 definitely agree that I'd expect the last one to be the one to appear if multiple=false. But if we use shift the portals will appear in reverse order if multiple=true.
Maybe we could change the last line of ownTransports (in portal-target) to this instead:
return transports.length === 0 ? [] : [transports[transports.length - 1]]
For an additional feature idea:
Maybe it would be nice to add a :order prop to portals so users can decide in which order the portals should appear when multiple is true.
(Although I haven't actually thought of a use case yet, since I'm currently only planning to use multiple for moving all my modals to the end of the DOM.)
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, goping for the last element is even better I think. Will review in more depth this weekend.
Nice work, many thanks! :)
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.
necessary change in emitChange
emitChange (newTransport, oldTransport) {
this.$emit('change',
- { ...newTransport },
- { ...oldTransport }
+ [...newTransport],
+ [...oldTransport]
)
},
src/components/portal-target.js
Outdated
firstRender: true, | ||
} | ||
}, | ||
mounted () { | ||
if (!this.transports[this.name]) { | ||
this.$set(this.transports, this.name, undefined) | ||
this.$set(this.transports, this.name, []) |
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.
Unrelated to the feature, but I think this whole if
block (but not the rest) should be in created()
rather than mounted
so it's applied before first render.
test/unit/portal-target.spec.js
Outdated
@@ -1,11 +1,12 @@ | |||
import { expect, td } from './helpers' |
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.
Please respect the code style. This repo has space paddings for inline object notation.
This applies to all changed files, I won't repeat it everywhere in the review for brevity.
to: 'target', | ||
passengers: vNode, | ||
}) | ||
Vue.set(transports, 'target', [ |
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.
This change is correct and necessary, but was not applied to all test cases where Vue.set was used.
test/unit/portal-target.spec.js
Outdated
@@ -144,7 +152,8 @@ describe('PortalTarget', function () { | |||
}) | |||
return vm.$nextTick().then(() => { | |||
td.verify(spy({ | |||
to: 'target', from: 'source', passengers: vNodes }, | |||
to: 'target', from: 'source', passengers: vNodes |
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.
this should now receive arrays. spy([ ... ], [ ... ])
.
...when the emitChange
method in PortalTarget
has been changed as described further above.
Performed all the changes you requested in the review. |
Thanks, will take a look tonight and merge if everything passes. |
Hey, sorry for leaving you hanging a bit - my private life is eating up my free time slots I would need to thoroughly look at this and merge it. That situation should improve next week, and I plan to dedicated sir time to this project at next week's weekend. |
Don't worry about it. I'm currently using this branch in the one project where I need this functionality, so there's no need to hurry on my account. Hope your personal situation works out well! |
Sure, it's all fine - weddings to attend and contribute to, this kind of stuff. so nothing to worry about, but these things eat time. :D |
Thank you very much from this. I will try and add some more tests for this and add docs, then prepare a release. |
Adds a multiple prop to the portal-target that, when true, will display all portals with the same target instead of just the first one.
Haven't written any tests yet, but I'll gladly add some if there's a real chance this PR might be accepted.