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

Update to 1.x version of Aurelia #2

Open
tomasbonco opened this issue Oct 21, 2016 · 3 comments
Open

Update to 1.x version of Aurelia #2

tomasbonco opened this issue Oct 21, 2016 · 3 comments

Comments

@tomasbonco
Copy link

Hello, Aurelia Flux and Aurelia v1.x are not compatible. Will you find some time to make it working, please?

@tkhyn
Copy link
Owner

tkhyn commented Oct 21, 2016

Ahoj @tomasbonco,

Sorry I won't be maintaining aurelia-flux any longer. I'm not using it anymore in my projects as I have advantageously replaced it by a simpler custom implementation. I really do not have the time to maintain this lib at the moment, sorry.

@tomasbonco
Copy link
Author

tomasbonco commented Oct 21, 2016

Thank you for your quick response.

Can you share at least some details about your custom implementation to inspire me? I was trying to fix it (aurelia-flux), but because of lack of docs from Aurelia side, it really is difficult.

@tkhyn
Copy link
Owner

tkhyn commented Oct 21, 2016

My 'custom' implementation of flux mostly relies on convention and self-discipline. I realized that most if not all the events only had one listener so it was not worth using events and all the subscription / dispatch / dependency injection / flux enforcement machinery which sometimes created unjustified limitations. I ended up simply using methods like doSomething and onSomething on singleton classes that I call '[Something]Store' and which responsibility is to handle the data (in my case through an ORM and client-side databases). This is much more flexible to accommodate edge cases and performance is better but it adds some coupling and requires some discipline to respect the flux pattern (hence the do and on methods).

I also considered Redux and other libraries but there was always something I disliked or that would create unnecessary complication or performance penalties (either not enough flexibility regarding the way the data could be stored - I really needed that - or copying the whole branch of a data tree each time a property changed - I really disliked that) ...

I sympathize with your efforts to fix aurelia-flux. I went through this a few months ago, only to realize not long afterwards that I could have made things simpler quicker had I known exactly what I wanted beforehand ... In the end I think that if I had to maintain a client-side flux library I would probably rewrite it from scratch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants