Show HN: ReactCircle – Renders SVG circle and percentage | Hacker News Reader

Show HN: ReactCircle – Renders SVG circle and percentage

github.com

63 pointszzarcon50 comments

Very cool!

However, I'm getting very low FPS when dragging the slider in Firefox on OSX (especially when dragging long distance in a short time). Is this due to the SVG rendering performance of Firefox or due to your code?

Turning off animations doesn't seem to make a difference.

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

runs really fast in nightly however

I think the author already patched it and that's why you're not seeing the same problem. Now it runs faster for me, too. (But HN doesn't allow me to edit my original comment anymore)

That's generally the easy part of showing progress.

The difficult part is usually to determine how much time is still needed for a computation.

Yes, you are right.

But still: This is easy to understand (I think I got everything I'd need from the animated gif and the one code example). It looks like it's versatile and will save you at least half a day of googling, coding and testing (unless you are an expert in all technologies involved).

I upvoted it..

Which is not the goal of this component. Progress here can be a lot of things, such as of a task, or your fitness goals, or world domination.

Which reminds me that I need to update my demo, mentioned in this blog post, given the JS has somewhat bitrot since 2015: http://blog.worldmaker.net/2015/03/17/compradprog/

My theory, also described in the blog post, and which I felt like the demo demonstrated when its JS worked, is that the nice thing about radial progress bars is that with spin and "tail" movement you can use a radial progress bar for composite progress (progress of multiple individual tasks with defined progress composited together, including cases of "task discovery" where progress may only start later).

I felt that when done right it doesn't violate user expectations ("forward momentum"), and it's an interesting merger of the spinner and progress bar that could be used in some pretty complicated situations.

I should get that demo working again.

Congrats! Very nice looking. CC: consider adding a title (or desc?) element for accessibility. Although you have a lot of the info in text, I find adding a title/desc element to all svgs is a good habit.

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!

Brill job!! Love little do one thing well components!

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

extremely poor performance

lol.

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

You created a throwaway to post this comment? May I ask why?

why not?

I was working on the same exact thing in the latest days. In my opinion the transition stroke-dashoffset is too performance hungry to be really usable. I ended up throwing away my svg implementation to redo it in canvas.

If you're going stateful to handle timers remember to use requestAnimationFrame

Research shows that people are really bad at estimating and comparing angles instead of bars.

Don't use pie/circle diagrams.

Sorry I don't have a link to the pieces of research.

That's true when you have more than the ratio between two things. But IMHO just a ratio or percentage is perfectly fine.

Which can also be used intentionally as a feature.

It's common from users to expect that when given an exact number for progress (35%) that percentages are themselves exact and evenly distributed. How many people hear bug reports that it took extra time to move from 36% to 37% than from 35% to 36%, or were worried that the system might have been stuck or crashed at 54% because it took so long, from someone trying to eagle eye your progress indicator?

Just because you can give a progress percentage doesn't mean that the user needs to know the exact value of that percentage or be able to visually compare progress indicators as strongly as possible.

This is super cool. Nice work!

Reply on news.ycombinator.com