Card image flicker when state change

[a.o]

Thank for this great API & SD, it's working great.

Current Behavior
As per the animation below, the card has a flicker when the parent component state changes.

Expected behavior/code

I think it'd be desirable to disable the animation/flicker when state change

[a.o]

So I took a closer look and I think the flicker is caused by the loader overlay

[Kiko Beats]

Thanks for reporting, it would useful if you can host the code at CodeSandbox for debug it easier

https://codesandbox.io/s/qqr6knpvp6

🙂

[a.o]

Thanks @Kikobeats for the great work!

Here is a simple reproductionn of the behaviour I'm trying to eliminate. I'm proposing we make the ease-out loader transition as optional.

I think the ideal behaviour is to have the ease-out animation only when the component is first mounted but no animation upon subsequent parent component state update.

What do you think?

[Kiko Beats]

I think the ideal behavior is to have the ease-out animation only when the component is first mounted but no animation upon subsequent parent component state update.

The idea of the loader was to create a smooth transition when the resource is available on the browser layer.

I think the flick effect is happening because the image is already available and the animation is too short to be smooth.

Maybe we can make more precise trying to measure the quantity of time before the image is available and determinate if the transition is or not necessary.

but your words looks a good approximation, can you create a PR? 🙏

[a.o]

Thanks for the quick respond @Kikobeats.

As I said the animation is not really needed upon subsequent parent state change, it's only need to happen initially when the component image is loading, but once loaded, any subsequent parent state change should not result in that animation again since the image is already loaded.

I'm in the process of migrating from the iframely to microlinks, and right now I just manually removed the animation all together, for me this is better then the flicker. So first, I suggest we add a prop to enable/disable the animation since this is a viable option, and then we can evaluate a smarter way of doing the animation as you suggested. Maybe we could detect if the image is loaded and if so then avoid the animation all together.

I can try doing a PR once I migrate my code to microlink sand and get it to work locally.

[Brad Adams]

I hear you @aliogaili, however adding props to the SDK for minor use cases is something we've tried to avoid (when it can be achieved with a small site-wide CSS snippet, for example).

Once you've got an example ready for us to test with, it shouldn't be too tricky to amend the issue 👌

[a.o]

Yes, I agree I think it make sense to keep the props minimal and keep the API simple to use. So we've to make the loading more intelligent to avoid this flicker. With that said, I really don't think this is a minor issue, I've a Pintrest like board and a newsfeed and the constant flicker is really distracting since any update causes the entire board/newsfeed to flicker, so I'm not really sure how you guys managed to avoid this issue.

Anyway I think this is easily solvable I just need to play more with the code to avoid breaking anything.

[a.o]

Sorry for the delays on this, I've been evaluating Microlinks for different links and it's working great.

However there are few links (which I'm collecting a list of) that is failing to parse correctly but mostly it's working great, so thanks for the great work thus far.

Right now I just removed the animation and it's working fine for me but I plan to take a closer look once I get more time. I also think the initial parse performance can be improved by running the rules in parallel since the initial fetching is slightly slower relative to iFramely.

[Kiko Beats]

I think it's the same glitch problem that we have in the web

Did you have any under WIP? Happy to move this forward 🙂

[a.o]

Yes, I noticed this issue on the web site as well. But the solution I applied (disabling animation) worked well on chrome but didn't work on Firefox, there was still flicker for some reason on every state change.

So now I'm testing a new approach, I've simply added the following line to the component index file:

  shouldComponentUpdate(nextProps, nextState) {
    if (this.state.loading && !nextState.loading) {
      return true;
    }
    return false;
  }

I'm using a local data object so I've not tested the impact on remote fetching but I think it'd work as well. One advantage I noticed with this approach is that in addition to eliminating the flicker, it speeded up the scrolling of cards since it eliminated unnecessary re-render of the cards.

Do you've any caveat on adopting this approach?

[Kiko Beats]

not sure if this an SDK issue; after refactor https://microlink.io I don't seeing the flicker effect anymore.

Just I'm going to close until I can an edge case again