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

Feature/multiple portals in one target #80

Merged

Conversation

eschalks
Copy link
Contributor

@eschalks eschalks commented Oct 3, 2017

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.

@LinusBorg
Copy link
Owner

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.

@LinusBorg LinusBorg self-requested a review October 3, 2017 20:32
@LinusBorg LinusBorg self-assigned this Oct 3, 2017

const currentIndex = this.getTransportIndex(transport)
if (currentIndex === -1) {
this.transports[to].push(transport)
Copy link
Owner

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.

Copy link
Contributor Author

@eschalks eschalks Oct 5, 2017

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

Copy link
Owner

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! :)

Copy link
Owner

@LinusBorg LinusBorg left a 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]
       )
      },

firstRender: true,
}
},
mounted () {
if (!this.transports[this.name]) {
this.$set(this.transports, this.name, undefined)
this.$set(this.transports, this.name, [])
Copy link
Owner

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.

@@ -1,11 +1,12 @@
import { expect, td } from './helpers'
Copy link
Owner

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', [
Copy link
Owner

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.

@@ -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
Copy link
Owner

@LinusBorg LinusBorg Oct 8, 2017

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.

@eschalks
Copy link
Contributor Author

Performed all the changes you requested in the review.

@LinusBorg
Copy link
Owner

Thanks, will take a look tonight and merge if everything passes.

@LinusBorg LinusBorg mentioned this pull request Oct 12, 2017
@LinusBorg
Copy link
Owner

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.

@eschalks
Copy link
Contributor Author

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!

@LinusBorg
Copy link
Owner

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

@LinusBorg LinusBorg added this to the 1.2.0 milestone Nov 7, 2017
@LinusBorg LinusBorg merged commit b42bbbe into LinusBorg:develop Nov 19, 2017
@LinusBorg
Copy link
Owner

LinusBorg commented Nov 19, 2017

Thank you very much from this. I will try and add some more tests for this and add docs, then prepare a release.

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

Successfully merging this pull request may close these issues.

2 participants