-
-
Notifications
You must be signed in to change notification settings - Fork 40
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(router-view): add router-view layouts feature #25
feat(router-view): add router-view layouts feature #25
Conversation
Do we want unit tests - there are none at the moment for the router view? |
@charlespockert We'd love unit tests. We've got a new testing library that should make this easier as well. |
I haven't looked at the implementation yet...but this is really freaking awesome 👍 |
Code looks pretty good. @charlespockert Would you be willing to help update with once the new shadow dom implementation is in place? Did you test it out with animation on? @bryanrsmith @jedd-ahyoung Can you review? |
export class RouterView { | ||
@bindable swapOrder; | ||
@bindable layout; | ||
@bindable layoutView; |
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.
@charlespockert I don't see this property used anywhere. A quick browser search shows it.
Also, I think instead of layout
, we should use layoutView
to specify the layout view instead and remove layout
, that way should be more predictable for the user. Thoughts?
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.
@alvarezmario Yep there are probably a couple of lines that need refactoring/removing as it was a back/forth job with a couple of contributors. There's also bug too which I've found/fixed on my local. Just wanted to get the code out there/some discussion going really.
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.
@charlespockert Great. And what are your thoughts on using layoutView
? compose
has the same 3 properties, so users will be familiar with it.
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.
@alvarezmario I actually took the conscious decision to use layout
because I didn't like the caps in layoutView
:)
We actually need layoutViewModel
and layoutView
(one for the module Id one for the view - neither are required or mutual). You can also use layoutModel
too - on the element they would obviously be lower-case hyphenated.
So basically - I agree, it should be consistently named (I will tweak and PR again at some point this week)
@EisenbergEffect Absolutely happy to contribute (it's more fun than my day job!) I've not checked it with animation but I'm thinking it should work since it's essentially the same pipeline and still enlists in the compositon/transaction and uses the same view slot - I'll try that now. I'll also try and get some tests in place - I think it's wise to wait until the shadow DOM stuff is under way so we get an idea of what the API looks like for that, I'd like to be able to add named slots in here too which can pull parts of the target view in. With this and viewports it probably gives you all the scenarios you'd want out the box (both sides of the same coin, so to speak) |
https://gist.run/?id=677f5ca6a20b315a10d77d224be2cebb Example of using named slots to reorganise the app layout in the template as per master pages/MVC sections. This works fine with animation on my skeleton clone - just can't seem to get the animator kicking in on gist.run - must be missing something. Edit: Ah - fixed it - updated the link above (forgot to link the stylesheet!) I'll get some unit tests on there by the end of the week. |
Cool to see some tests! I'm working on Shadow DOM v1 implementation now. It's about 75% done I think. Later this week, might be a good time for you to take a look at the templating branch so you can see how this would work with the new version. I think this is a great feature. If you are up to it, there's another place this would also be useful: the compose element. Any interest in implementing this there as well once the Shadow DOM update is in place? |
@EisenbergEffect this is indeed a great featured. Previously I had to use child routers to achieve this, now it'll be easier. An example is homepage, which usually have a complete different layout than other pages in the application. |
@EisenbergEffect happy to take on whatever you need help with - give me a shout when you think the Shadow DOM stuff is complete enough to be pulled into this and I'll take a look. |
Blog post on the new Shadow DOM v1 implementation is here: http://blog.durandal.io/2016/05/23/aurelia-shadow-dom-v1-slots-prerelease/ |
this allows a user to specify an additional view/viewmodel per route which is used as a "layout", this layout must contain a content selector where the content of the module specified in the route will be transcluded. This allows developers to provide different layouts for different areas of their application similar to MVC layouts/ASP.NET master pages
@EisenbergEffect thought I'd give you a quick update. It's working with the Shadow DOM feature - I've not updated the package.json at the moment (since there's no npm release yet) Tests run with the current config.js but that will probably need to change upon release (could do with some more tests as well). Obviously usage is as you would expect: layout.html
your-view.html
|
Cool. I think enabling this for the router is a real killer feature, especially since slots support fallback content. For the moment, we can keep this PR open here. If you can, please continue to add more tests to any aspect of the code. That's a huge help. Let me know if you have any other questions or concerns, otherwise, we'll probably merge this in in another week as we begin the preparations for RC. |
Just reviewed the code...looks like the new API we built made this cleaner to implement as well. How do you feel about it in the end? @charlespockert |
let viewSlot = new ViewSlot(layout.firstChild, false); | ||
viewSlot.attached(); | ||
|
||
swapStrategy = this.swapOrder in swapStrategies |
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.
@charlespockert this code is repeated. Could you refactor it?
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.
@alvarezmario yep certainly agree I'll refactor these
@EisenbergEffect yes the shadow DOM is a little cleaner content selectors on the whole but I did take a couple of small things out (no check to warn the developer that they forgot to put any slots in their template for example). I'll iron out any potential niggles when I add more tests and refactor |
@EisenbergEffect having some trouble here, seems like when I use the It works fine for non-named slots - any ideas? I was thinking maybe mixed dependencies, but I've checked and I'm only loading 1 version of pal-browser/templating in the browser (the shadow DOM versions) It's undefined here: But not when the |
Are you tests set up to initialize the PAL? That's the only reason I can think that might cause that to be undefined. |
@EisenbergEffect not explicitly, I'm initialising aurelia via the testing framework and it works fine with any tests that use the DOM without using the I think there are other places where I'll keep digging, though I'm on holiday now until the weekend so progress will be minimal (and by that I mean zero) |
@charlespockert Do you have any interest in implementing this for the |
Yes, I'll definitely have a go at that too in a few days when I'm back
|
@EisenbergEffect ok, managed to get it all working, it was the call to initialize I was missing, the DOM object was there at the time of loading but What's the plan for deps etc? If I just put this PR in as it is will you tweak deps as needed when you prep for release? At the moment the deps for tests point to the github repos |
@charlespockert here aurelia/fetch-client@a97fa7b there are several library updates, so perhaps is better to have an individual PR for that. |
@charlespockert We'll fix up the deps. No need to worry about that. |
@EisenbergEffect should be good to go I think - any suggestions from your side? I've included deps needed in |
I'll do a final review in the next couple days and let you know if anything else is needed. Thanks! |
@charlespockert There any way to load module with html only like this layout feature ? config.map([{route:'route', moduleId: 'test/module-view-only.html' }]) I'm searching for solution by days, but I did not find anything. So, I write a little modification in router-loader.js: commit and tests This code is really necessary to load a html by route-view? |
this allows a user to specify an additional view/viewmodel per route which is used as a "layout", this layout must contain a content selector where the content of the module specified in the route will be transcluded