Skip to content
This repository was archived by the owner on Sep 8, 2020. It is now read-only.

feat: Programmatically toggle containers #154

Merged
merged 3 commits into from
Nov 16, 2015

Conversation

petrsimon
Copy link
Contributor

Enables:

Enables:
- programmatically un/collapse containers using collapsed attribute
- collapsing containers on app start (see comment in directive uiLayoutLoaded)
- introduces concept of "central" container
- add animation for collapsing
- fixes angular-ui#129, angular-ui#100
- few formatting changes
@j--w
Copy link

j--w commented Nov 4, 2015

@petrsimon created a plunker to demonstrate these fixes here: http://plnkr.co/edit/u8hJG42cMQDg9KiG86as

Unfortunately a couple of tests are failing, @petrsimon have you had a chance to look at the failing tests?

@petrsimon
Copy link
Contributor Author

Weird. On my system, I see 61 test running, all passing. Can you tell me which ones?
Edit: and thanks for including the link to plunker.

@j--w
Copy link

j--w commented Nov 4, 2015

It looks like it's the splitMove tests have a look at the log here for more detail: https://travis-ci.org/angular-ui/ui-layout/builds/88887198

@petrsimon
Copy link
Contributor Author

Ah, thanks. I've missed that. I thought it's just the jshint, since it's all passing on my computer.

@petrsimon
Copy link
Contributor Author

I see, it's failing on Firefox 31, I've got it passing on 41. Are we supposed to support browser that old?

@j--w
Copy link

j--w commented Nov 4, 2015

I'll defer to @SomeKittens for that question but I would assume so as all the other angular-ui stuff on travis seems to be running tests in that version.

@petrsimon
Copy link
Contributor Author

Right. That naturally makes sense. Just not sure how to go about fixing this...

@petrsimon
Copy link
Contributor Author

Just ran the test with FF31.
Firefox 31.0.0 (Mac OS X 10.11.0): Executed 61 of 61 SUCCESS (2.393 secs / 2.212 secs)
Not sure what to do next.

@j--w
Copy link

j--w commented Nov 4, 2015

I just pulled down your branch to my local and the same tests fail for me in chrome 46 and firefox 41 but pass in phantomjs. Any ideas? I may be able to do a bit of digging tomorrow.

@petrsimon
Copy link
Contributor Author

OK, I can reproduce it now, only on Chrome, though... (on OSX) (confession: actually I didn't have stable chrome installed and I forgot to turn Canary on, that's why I missed it). Thanks a lot and also for the eagerness to dig!

It bugged me, so I had to take a quick look. It's caused by rounding down.

To recap what is going on in the test:

  1. Initially, the available space (minus dividerSize) is divided by the number of 'auto' sized containers, two in our case. See line 311. This number is rounded down, which means that there's 1px border left at the bottom in case of odd numbers. Splitbar top is this rounded down number.
  2. On toggle, this branch stores the actual size of the container in uncollapsedSize property and uses it during the next recalculation, where available size is divided by one (remaining 'auto' sized container), which means that the splitbar top is shifted by 1px up.

The test is working outside this branch, because originally toggle{After,Before} were simply adding/subtracting the original size and leaving the 'auto' container as it was (including the dangling 1px, of course).

How about if in case of odd numbers, we add the remainder to the last 'auto' sized container and adjust the tests.
Does that make sense? @BobbieBarker and @SomeKittens do have any comments?

@SomeKittens
Copy link
Contributor

Opened #156 to cover browser testing.

And yeah, rounding is fun! I'm fine with adjusting the tests to cover reasonable off-by-one cases due to rounding.

@petrsimon
Copy link
Contributor Author

Thanks @SomeKittens!
Sorry, my explanation above is perhaps little unclear. I thought this is a browser issue at first, but see my notes on the "dangling pixel". We need to fix that and modify the tests. It should than work on all browsers again. Otherwise the test fails randomly based on the initial size of browser in karma, which in some cases is odd (pun intended).

The current tests are simply testing a bug, which is caused by rounding in the code (not default sub-pixel value rounding in the browsers). Hackish way to fix the test would be to resize the viewport in beforeEach to even numbers.

But I guess the best way to do it is to add the dangling pixel to the last auto sized element.

@j--w
Copy link

j--w commented Nov 6, 2015

I think adding the dangling pixel to the last auto sized element makes sense.

c = ctrl.containers[i];
opts.sizes[i] = c.isCentral ? 'auto' : c.collapsed ? '0px' : optionValue(c.uncollapsedSize) || 'auto';
opts.minSizes[i] = optionValue(c.minSize);
opts.maxSizes[i] = optionValue(c.maxSize);

if(opts.sizes[i] != 'auto') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

!== vs !=

@BobbieBarker
Copy link
Contributor

I'm also fine with adjusting the tests to deal with the scenario. I just did an initial review I found a few style issues. I'm going to try and review it again to dig into more of what you're doing etc before I sign off, but initial review looks good. Should be able to get it merged in pretty quickly after the tests are fixed.

@petrsimon
Copy link
Contributor Author

I didn't want to mess with the style too much, since I've got more ideas in that area and thought I'll do another PR for that, but those few small changes you've mentioned, I'll change right away. I've got the dangling pixel basically taken care of, just have to fix the test and see that it doesn't brake anything else.

@SomeKittens
Copy link
Contributor

Yeah, there's a few lingering style issues I'd like to fix but haven't yet. Thanks for following what you saw.

Good news about the pixel! Looking forward to it.

@petrsimon
Copy link
Contributor Author

Will do my best! :)

Remainder from rounding down of autoSize value is added to the last
container of a layout.

- Tests adjusted to account for the new container sizing
- Few style fixes as suggested during PR review
@petrsimon
Copy link
Contributor Author

Please have a look.

@SomeKittens
Copy link
Contributor

Latest commit LGTM

@petrsimon
Copy link
Contributor Author

My pleasure! Let's see if others find anything fishy...

@BobbieBarker
Copy link
Contributor

LGTM as well, it looks like jshint failed on your build though. Fix and we'll accept. Also, thank you for putting up with all the back and forth, your contribution is definitely welcome!

This is temporary formatting change, which should later be revised.
@petrsimon
Copy link
Contributor Author

No worries, happy to contribute.
I've pushed a temporary fix for the jshint warning, which doesn't reformat the whole file. I would personally consider switching to $inject property or even better to ng-annotate later.

BobbieBarker added a commit that referenced this pull request Nov 16, 2015
feat: Programmatically toggle containers
@BobbieBarker BobbieBarker merged commit e3461bb into angular-ui:master Nov 16, 2015
@BobbieBarker
Copy link
Contributor

PR accepted, this project needs a lot of TLC if you'd like to submit additional pull requests to deal with short comings etc you're more than welcome to.

@petrsimon
Copy link
Contributor Author

Wonderful! Thank you. I'll have couple of other ideas, so I'm planning to make issues or PRs soon.

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

Successfully merging this pull request may close these issues.

Create CONTRIBUTING.md
4 participants