Hacker News new | comments | show | ask | jobs | submit login
Show HN: ReactCircle – Renders SVG circle and percentage (github.com)
63 points by zzarcon 6 months ago | hide | past | web | favorite | 50 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.


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.


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.


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


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?


lol.


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.


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.


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


This is super cool. Nice work!


[flagged]


Your comments reads in bad taste. Maybe be more constructive?


[flagged]


This is why we can’t have nice things.

To many times I’ve seen these kind of comments on GitHub, HN, ShowHN.

Our field is filled with people who lack a 101 in constructive feedback and context awareness and it breaks my heart. Who would like to ever contribute again if this was the response they got on their first contribution?


Still condescending if you ask me. Be constructive, his work is free and nobody forces you to use it. If your goal was to help the guy...you failed; "that had to be a challenge, but you did it".


Incredibly poor attitude. This is free, open source software. You did not pay for this. If you found a bug and you don't want to wait for the developer to fix it, then fix it and make a PR.

There is nothing wrong with making a post stating that you've found a bug. There is a problem with acting entitled like you are, and insulting the developer in the process.


>Incredibly poor attitude. This is free, open source software

so we're no longer allowed to criticize poor things we don't pay for?


There's a difference between "hey man you should check this with a throttled CPU" and "I hope developer of this component never makes a single webpage."


You hope they never make a single page? You can’t improve your skills as a developer? You started out brilliant?

This is a bad way to deliver criticism, especially on a ShowHN.


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/


Without knowing anything about the implementation, I'd guess this is not a case of using CPU/GPU a lot and causing a subsequent slowdown, but a case of a misplaced/misconfigured debounce function.


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.


That's Firefox on arch linux


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


I actually work on low latency Java backends, I have no idea how this works ;)


> 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.


Given there's only a single svg element changing I'm not exactly sure you could have done it better.

It might just be that the ease-out transitions for the stroke are not efficiently implemented in whatever browser you're using.

If you've tried and check out and understand the code you'd see there's so little being done in JS that this stuff is surely not the bottleneck.


Use a canvas and render the component directly? You’re rendering a circular progress bar, that should be easily doable in microseconds if not nanoseconds. There’s no need to use the overly bloated DOM for everything.

I suggest taking a look at Android’s views or even Flutter.


But there's only 3-4 DOM elements. I'm pretty sure doing this in canvas is not as trivial as this.


Of course it’s not as trivial. But you can control the animation much better, and you can have much better performance.


Yeah, more than likely the only problematic part is the transition animation. The main problem was another component breaking the performance in the examples page, not the component itself. Should be fixed now :)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: