That's pretty neat! thanks for sharing

Can you elaborate why we should use IntersectionObserver/ResizeObserver?

Currently there is no logic in place to do the calculation and detect if there is more available content or not, so I'm 100% sure if understand the issue

I guess it doesn't have to be a React component, you are right. But just by doing so you get a lot of things for free and makes it easier for people to start using it, like, you just install it, require it, and you are good to go... that was the motivation beyond using React for it

Oh sorry about, I copied that from a previous project I did, just published a fix for that. Thanks!

Thats a good point, just created an issue for it https://github.com/zzarcon/react-circle/issues/12 feel free to put some feedback there, thanks!

I fixed the issue, was unrelated with the component itself, can you please have a look again and verify that it works fine? https://zzarcon.github.io/react-circle/

Can you please try it again? the issue was not related with the component itself https://zzarcon.github.io/react-circle

let me know if you still experience that issue

If you turn off animation it's snappy.

I'd recommend either killing that altogether as it definitely gives the perception of bad performance.

Or... at least take into account the delta of the progress change when doing animation. For instance, if going from 5 to 10%... a slower animation is fine. If going from 0 to 100%, the animation should be much quicker.

The performance is still bad. It's spending roughly 20ms doing JS work per frame.

React profiles are not very easy to interpret but perhaps you're doing a lot more work per frame than you should be?

Here's the profile: https://perfht.ml/2F7ohwx

This file is the entire source of the component: https://github.com/zzarcon/react-circle/blob/57bb4d19df08b73...

A lot of the work seems to be the React diffing? The only thing that changes between frames when dragging the slider is the style attribute.

Furthermore, the author seems to have included the development version of React. And the author used development settings for the webpack compilation. The compiled JS is full of eval() calls.

It might be slightly better, but still far from performance I would expect from that component

https://gfycat.com/TerribleWeeArmadillo

Is this Edge? I can confirm poor performance in Edge, but every other browse I've looked at seems to be ok.

Interesting... will have a deeper look into it, if you have any idea on how to make it better you are welcome

> low latency Java

(Does not compute)

Sure it doesnt ;)

The think that myth is coming from the fact that JVM is heavy (150MB?), so it takes time to start, and hot-spot needs some iterations on a source code before it can fully apply JIT, but other that that, Java is really good.

Thanks! That was the motivation for the project, do something simple right, feel free to add any feedback or contribute to the repo!!

After some investigation, I found that the cause of the issue is not the component itself https://github.com/zzarcon/react-circle/issues/10

Thanks for the feedback! You are right, the demo currently hangs quite a lot on Firefox, Im pretty sure the issue is actually not related with the component itself, I created a issue on the repo to fix it https://github.com/zzarcon/react-circle/issues/10 :)

Thanks! That already works a lot better.

To further improve things, I would suggest two changes to your webpack config:

1. Use the production version of React. It seems that you are using the slightly slower development version. (In webpack this is done by defining process.env.NODE_ENV = "production" and eliminating dead code afterwards)

2. Stop using webpack in development mode for your deployment. There are 272 eval() calls in your bundle because of this: https://raw.githubusercontent.com/zzarcon/react-circle/c1480...

Both of these things are already taken care of by the production mode in webpack 4.

You are so right!!

Im using an external tool for deploying the site, created a PR there to use production mode, do you think that should be enough? Thanks! https://github.com/zzarcon/ts-react-toolbox/pull/2

It looks like the whole app is re-rendering every frame instead of just having the stroke properties animate: https://perfht.ml/2vEbUc6