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

counter animation glitches #1

Open
bramdeba opened this issue Jan 11, 2022 · 8 comments
Open

counter animation glitches #1

bramdeba opened this issue Jan 11, 2022 · 8 comments

Comments

@bramdeba
Copy link

bramdeba commented Jan 11, 2022

The animation glitches. Any idea what may be causing this?

Kapture 2022-01-11 at 17 33 18

image

@bitttttten
Copy link
Owner

Hi @bramdeba ! Sorry I didn't see this earlier. Which font are you using? I can try and reproduce and let you know what's up.

This is a custom font, right? My first instinct is that the library could be calculating the spacing of the digits before the font is loaded. Or at least the library is failing to calculate the spacing properly.

You could try only displaying the component after the fonts have loaded, just to see if it fixes your issue. If it does then there is work to be done in the library :)

I would do something like this, just to test that it is the font loading causing the issue.

function useAreFontsReady() {
    const [state,set] = useState(false);

    useEffect(() => {
        document.fonts.ready.finally(() => {
            set(true);
        });
    }, []);

    return state
}

Then you can use it like

const areFontsReady = useAreFontsReady();

return areFontsReady ? <CounterAnimation text="testing" /> : null

@bitttttten
Copy link
Owner

Actually, that code able is in the repo already! Although if you can provide a bit more details about your environment, it might help me look into it.

I had actually noticed that I am not setting the font for the counter in the best way. It seems that the API is not very consistent across all browsers. So this line:

context.font = getComputedStyle(ref.current ?? document.body).font;

is very different in some browsers than others, and in some browsers, I was noticing that getComputedStyle().font does not return the font family, only the font size. So therefore the calculation will not be correct since the font is not set. I am using the canvas to measure the width of each letter, and the canvas font is not being set correctly, therefore the width of the letters is not being read correctly.

I am not sure if that is the problem for you, but it is a problem I have noticed.

@bitttttten
Copy link
Owner

I just released 1.0.14 although not sure it totally fixes it for you. Curious to know which browser and font combo you have.

@johndebord
Copy link

I'm having the same exact issue. Currently using Google Chrome Desktop and Safari iOS

@johndebord
Copy link

Narrowed down the problem; the bug appears when specifying margin=auto of a container element containing a MechanicalCounter

@bitttttten
Copy link
Owner

@johndebord Very cool that you were able to get to the bottom of it and thanks for sharing. Are you able to provide a reproduction? Perhaps in codesandbox or something? As I cannot reproduce here even with your description

@commandZeta
Copy link
Contributor

I have a similar problem with the rendering of the elements

  • For some reason there is a problem in the animation of the wheel when the number 9 appears. When going from 8 to 9, or when going from 9 to 8. It just does it without animation.

  • And in my case, I also find failures applying mechanical-counter on the calculation of an amount $. It happens in some cases (rarely, not always) and it only occurs with the number 0 (in amounts like $24.900 only on the first zero). The number that I put in the text property is calculated by 'myFunction' which returns:

<MechanicalCounter text={ myFunction(price*quant) } />

return(
   new Intl.NumberFormat('es-AR', {
     style: style,
     currency: currency,
     minimumFractionDigits: 0
   }).format(calculatedAmount)
)

Reviewing the rendered HTML I see that it misapplies the location on the translate3D property, it displaces the numbers much further than they should, at the same time which leaves it with opacity 0.

For what it's worth, I had some issues between mechanical-counter and framer-motion (v 10.12.18) when installing the dependency. I think I fixed it by reinstalling framer-motion with "npm install framer-motion --legacy-peer-deps" but I don't remember exactly now

@bitttttten
Copy link
Owner

@commandZeta it could be some kind of framer-motion bug, maybe my code is also not very optimised 😅

the peer dep is "framer-motion": "^4.1.17",, although i imagine this would work with many other framer motion versions so i hope installing a different version fixes it 😬

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

No branches or pull requests

4 participants