Open brillout opened 7 years ago
@androidfanatic @VikLiegostaiev @Javier-Rotelli
Thanks for your feedback. What is it you don't like about the new version?
I would love some search filters such as "stars>200" or "lastUpdated<1month".
Sorting by stars/commits/issues/update date etc.
This is a little hard to digest all at once, organizing these under appropriate categories would be great
Also slightly color coding repos by commit activity would help us gauge which repos are active and which to avoid. Active ones should be green (or maybe have a little green dot next to the name) while the old ones would be red.
@AdityaAnand1
Thanks a lot. Deeply appreciate it! And it helps.
I would love some search filters such as "stars>200" or "lastUpdated<1month".
Trying to understand; Why do you need this?
Sorting by stars/commits/issues/update date etc.
Same as above; What is it you want out of a sorting by stars/issues/...? Feels like devarchy can't provide on something you are trying to achieve but I'm not sure what it is.
This is a little hard to digest all at once, organizing these under appropriate categories would be great
Ok yes true. I've an idea about that. Basically: tag can be tagged. We can then get hierarchical tree (/forest) of tags. Needs
would then be categorized in this tag tree. We then get the same tree structure than we have currently on awesome-react-components github repo's readme.
But tagging tags could be confusing as I've not seen such practice before. Not sure.
Also slightly color coding repos by commit activity would help us gauge which repos are active and which to avoid. Active ones should be green (or maybe have a little green dot next to the name) while the old ones would be red.
Never thought about using colors that way, very interesting.
How would you define "active"? Some repos with low LOC need less maintenance.
Redux e.g. had only 7 commits in the last month (https://github.com/reactjs/redux/graphs/contributors?from=2017-10-01&to=2017-11-02&type=c). Yet Redux should be a full green. Seeing Redux redish on devarchy would be confusing to people that don't know how we compute the active color. What do you think?
@androidfanatic @VikLiegostaiev @Javier-Rotelli
friendly ping! I think it would be only fair if you guys elaborate on what it is you don't like if you downvoted this ticket in the first place. Sorry to be annoying:) & thanks in advance.
Javascript changes rapidly. I'd much rather commit to using a repo that's active and popular instead of one that's old and obscure.
Seeing Redux redish on devarchy would be confusing to people that don't know how we compute the active color
What I meant was that commit activity would be ONE of the factors determining the color used to highlight. In redux's case, the high number of stars/commits/releases/contributors would far outweigh the low activity. Several factors would have to be combined to come up with useful recommendations. This will probably take a little trial and error to tweak the algorithm.
I'd much rather commit to using a repo that's active and popular
Yes and that use case is on top of my mind.
Why is the following not enough for you to determine what library is stable?
In my case I'm mostly happy with that; I can quickly skim over and see which one are popular and recent. Going for popular and recent is how I choose (for my use-case) functionally equivalent libs.
the algorithm
What I'm afraid with such approach is the lack of transparency; A user has no clue how the active color is computed.
I actually didnt see the site before the update so I dont know if there is a difference, but scrolling is very janky on mobile. Im using a iPhone 7. So much that its quite a bad experience 😬
I’m guessing it has to do with scroll-listeners. Maybe you could use debounce to minimize unnecessary js-execution? for example in tags-list.jsx
@hontas
I'm surprised to hear that you search libraries on your phone. Do you mind me asking why mobile and not desktop? I never searched for a library on my phone before.
I only use passive scroll listeners so that shouldn't be the issue. The whole view is rendered on the server but also re-rendered on the frontend. I expect the client-side re-rendering to be the cause. I'll experiment with React fiber which could translate in a smoother experience on less powerful computers.
Thanks for feedback, I appreciate it. Is there anything else that would help you find libraries?
@brillout if you don't want it to work well on a phone, thats up to you, just sayin' ;)
It’s a good start! Just needs some ironing out—love that you’re using GH for feedback.
On handheld, back and forward buttons don’t work. I have to manually close a modal for a library/detail view. Hitting back/forward does something, but the modal remains on top so I can’t tell what’s going on behind it.
scrolling is also very difficult—it looks like something is handling scroll, because there’s no easing on the scroll when I let go. The page just comes to a dead stop. Also, code blocks seem to be swallowing touch events. You can’t scroll at all if the entire viewport is filled with a code block. Will see about attaching vids/gifs.
Thanks @joeyfigaro! I'm busy right now with https://github.com/reframejs/reframe but I want to get back to devarchy at some point in the future.
Thumbs up/down this ticket if you like/dislike the new version.
The new version can be seen at the React catalog at devarchy.com/react.