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

Migrate to react.js or vanilla js #44

Closed
hirwandzahir opened this issue Sep 24, 2017 · 12 comments
Closed

Migrate to react.js or vanilla js #44

hirwandzahir opened this issue Sep 24, 2017 · 12 comments

Comments

@hirwandzahir
Copy link

Hi,

Just want to know if percircle support angular 2/4?

@teobais
Copy link
Owner

teobais commented Sep 26, 2017

Hello @hirwandzahir ,

thank you for your interest in percircle!

To be honest, I do not see this happening for the near future, since I don't have the required time capacity, at the moment.

However, I would be happy to review a pull request that does so.

@teobais
Copy link
Owner

teobais commented Aug 29, 2018

It's been a while, but I feel like asking this question.

If we're talking about a potential investigation of porting percircle to one of the modern frameworks, what should that be? What would best serve the purpose of this project?

  • Angular?

  • React?

  • Vue.js?

How does the community feel about this?

@teobais teobais changed the title Support Angular 2/4 Support Angular 2/4 ( / React / Vue) Aug 29, 2018
@chris--jones
Copy link
Contributor

I feel this project is not suited to modern frameworks because the approach and toolset doesn't suit them.
It is uncommon to use jQuery these days as newer js frameworks are transpiled and modern javascript can easily handle a lot of what jQuery does.
Alongside the decoupling of jQuery there would need to be a fair bit of refactoring to be a bit friendlier for integration - e.g. the individual options should be able to be adjusted without having to re-render the entire control (e.g. percent), this is a particular concern for React.

@teobais
Copy link
Owner

teobais commented Oct 13, 2019

Thanks a lot for your input, @chris--jones .
Moving to react.js sounds indeed right at the moment.

Would you like to pick this up?

@chris--jones
Copy link
Contributor

I am also time poor at the moment, I will revisit if I get a chance.

@teobais teobais changed the title Support Angular 2/4 ( / React / Vue) Migrate to react.js Oct 20, 2019
@chris--jones
Copy link
Contributor

Here's my 2c worth:

Therefore, I would consider that if we're going to enter the arena as an alternative we should probably consider:

  1. Focusing on the core objective - This is one of my main concerns with the project - it should focus on a percentage based circle, nothing more.
    e.g. Adding support for clocks and countdowns added unnecessary complexity and maintenance effort. It's also quite likely someone will come along with a new requirement or need a slightly different clock or countdown and be unable to produce it with the plugin as it is. We should offer a nice api that makes implementing these things easy rather than implementing everything. I'd probably extend this to the color themes, although management of the css is considerably less maintenance effort with Feature/webpack #59 given the less variables, functions and autoprefixes.

  2. Offering different framework options - React just takes care of the rendering and state management side of frontend, there's no reason we couldn't refactor this project and provide a React component as a plugin that utilises a large amount of core code.

  3. Maintaining backwards compatibility - If people are using it because they can't support SVGs (although in this day and age I can't imagine that being reality) or can't use a modern framework (legacy systems, fair enough) then dropping that support would prevent this project standing out against the alternatives.

  4. Offering different render options - SVG really is the superior rendering option here, the main limitation of the current approach is that the background must be a filled colour (although I've been experimenting and may have figured that part out). We could probably refactor and offer both render options.

All this is a big ask and rather opinionated, but I think it's important enough to discuss before anyone jumps into a major coding effort.

@teobais
Copy link
Owner

teobais commented Oct 29, 2019

Hey @chris--jones , thanks a lot for taking the time to provide your input.

Backward compatibility should be indeed there, so what we developed up until this moment shouldn't just vanish all of a sudden.

Moreover, I concur to anything else that you pointed out. Could we initiate a new branch and start making some progress step-by-step in there?

@teobais
Copy link
Owner

teobais commented Dec 3, 2019

Hey @chris--jones , any updates here?

@chris--jones
Copy link
Contributor

Nothing worth sharing yet, it's still early stages, but if you want I'll push a very barebones restructuring of the library as soon as I can.

@teobais
Copy link
Owner

teobais commented Jan 11, 2020

Any news here @chris--jones ?

@chris--jones
Copy link
Contributor

Not yet, I have been away and still time poor.

@teobais teobais changed the title Migrate to react.js Migrate to react.js or vanilla js Dec 13, 2020
@teobais
Copy link
Owner

teobais commented Jan 15, 2022

#85 introduced a Vue implementation which renders this issue redundant at this moment. Closing.

@teobais teobais closed this as completed Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants