ngAnimate with angular-masonry (+v1.2)

[jorguema]

In order to make custom animations with this directive, i tried to import ngAnimate ( in this case v1.3.0 ).

When i try to apply some animation to a ng-repeat element, this custom animation don't works, and if include ng-Animate to my app module, with the example of demo page, the custom transition to append an element to a masonry div don't work.

is this directive compatible with ng-Animate? how i can do them work?

Anyway, can i change transform and transition made by default?

Thanks you, and thanks for this directive

[passy]

@jorguema I haven't tried this myself. Do you have example code for this?

[abbood]

@passy well this is kind of related.. but if I load a div with preloaded content and images.. it displays just fine:

however if i make the masonry div appear as a result of ng-animate.. it comes messed up:

code: this is my jade(html) code:

    detail-page.detail-page-animation(ng-class="{active:isAnnotationClicked}", is-annotation-clicked="isAnnotationClicked", is-annotation-hovered="isAnnotationHovered", current-annotation-data="currentAnnotationData")

and

.body
  .title {{listing.header}}
  .stub(masonry, item-selector='.card')
    .card(masonry-brick)
      .container
        strong {{listing.listing}}
        .caption For Sale: $ {{listing.price}}

    .card(masonry-brick)
      .container
        header Description
        hr
        .body {{listing.description}}

    .card(masonry-brick)
      .container
        header features
        hr
        .bedrooms Bedrooms: {{listing.beds}}
        .bathrooms Bathrooms: {{listing.baths}}
        .parking Parking: {{listing.parking}}
        .area Living area: {{listing.size}}
        .features Features: {{listing.features}}

    .card(masonry-block)
      .container
        .body

    .card(masonry-block)
      .container
        header rate this property

    .card(masonry-brick)
      .container
        img(ng-src="{{listing.img}}")

and inside my animations.coffee file:

.animation '.detail-page-animation', ->
  animateUp = (element, className, done) ->
    return  unless className is "active"
    element.css
      bottom: -500

    jQuery(element).animate
      top: 40
    , done
    (cancel) ->
      element.stop()  if cancel
      return

  animateDown = (element, className, done) ->
    return  unless className is "active"
    element.css
      top: 40

    jQuery(element).animate
      bottom: -500
    , done
    (cancel) ->
      element.stop()  if cancel
      return

  addClass: animateUp
  removeClass: animateDown

[amergin]

I am, too, seeing a strange issue when using angular-masonry in a module that depends on ngAnimate.

I noticed the other issue where @passy mentioned that Angular-masonry can be adapted to Packery.js use as well. I looked into it, and it seems to work perfectly, but as soon as angular-animate comes into play, the transitions and dragging events of bricks are somehow cut short. It's as if the library intercepts adding those styles to elements and does some own logic on them.

Any ideas how to make angular-masonry compatible with angular-animate?

Edit: here's a demo. Notice how the transitions and dragging the bricks from the black handle box act differently once you remove the ngAnimate dependency.

[mflorence99]

This is just a question that you may be able to answer from the design decisions you made when writing the code. I'm very happy to dig deeper but I wanted to check first.

I'm using angular-masonry with ui-router and ng-animate. I'm noticing a visual anomaly during a "slide" view-to-view transition. The ui-view containing the masonry is slid out at the same time a new ui-view is slid in so for a period of time both views are visible.

The anomaly is that while the masonry ui-view is sliding out, its layout collapses and all images are stacked just as if masonry had never done its work. This is caused by the destroy code ~line 96:

      this.destroy = function destroy() {
        destroyed = true;
        if ($element.data('masonry')) {
          // Gently uninitialize if still present
          //$element.masonry('destroy');
        }
        $scope.$emit('masonry.destroyed');
        bricks = [];
      };

You can see that if I comment out the $element.masonry('destroy') and let the DOM do the cleanup, the anomaly doesn't occur. I've done some preliminary heap analyses and I haven't seen a memory leak -- yet :)

I'm just checking to get your opinion on whether that explicit destroy is necessary. Many thanks!