Open EisenbergEffect opened 9 years ago
This plugin is terribly effective, any chance it can become part of Aurelia proper?
Sorry for the delays in fixing the plugin. Was terrible busy with my "day job". Am just fixing what's broken and hopefully will have the plugin fully working within 1-2 days.
Anything able to put out or a direction for updates if we wanted to tackle this ourselves? This is the only thing preventing us from upgrading at the moment.
Fixing the plugin requires the latest master of Aurelia's DI, which hasn't been released yet. We plan/hope to release it next week.
@tfrydrychewicz Everything should be released any chance we can get this updated today? I know a lot of people are very anxious for this which means it's being used a lot
+1 for the update, my last Aurelia update: Aug 2015. Tried to update it since last month, still has no success.
@tfrydrychewicz There's a new release containing the features you need in the DI to update this.
@tfrydrychewicz Any news on the update of your great plugin? I am looking forward to it!
@EisenbergEffect Since aurelia-flux seems to be very popular, is there a chance that it becomes official?
This plugin is also blocker for me to update to the newest Aurelia version. Looking forward to see it updated. @tfrydrychewicz Thank you for the great job!
@EisenbergEffect what was the functionality added in DI to allow this to get updated?
container.container.setHandlerCreatedCallback
was added. Here's the notes I sent to Tomasz in the gitter channel after it was added...
container.setHandlerCreatedCallback(handler => {
//this callback is called once per type that the container will instantiate
//so, for Foo, it will be called once during the application lifetime
//but you can inspect what the container finds, change it and...
//control how instances of that type are created thereafter
//so we only have to change the invocation when the type actually has a dependency on Dispatcher
let index = handler.dependencies.indexOf(Dispatcher);
if(index !== -1) {
handler.dependencies[index] = new DispatcherResolver();
let invoke = handler.invoke;
handler.invoke = function(container, dynamicDependencies) {
let instance = invoke.call(handler, container, dynamicDependencies);
container._lastDispatcher.connect(instance);
container._lastDispatcher = null;
return instance;
};
}
return handler
});
//a custom resolver's get is invoked by the container to "resolve" an instance
//we use a special resolver so we can capture the instance for later use in our invoke fixup
@resolver
class DispatcherResolver {
get(container) {
//not sure how you want to create it, but do that here
//and then store it temporarily on the container, so you can grab it later
return container._lastDispatcher = container.get(InstanceDispatcher);
}
}
class InstanceDispatcher {
connect(instance) {
//do what you want with the connected instance
}
}
You probably need to push/pop a dispatcher array on the container, actually, instead of having a single _lastDispatcher
property, because of recursive resolver get calls. But, hopefully you get the idea.
Hi @tfrydrychewicz,
can you please share any news on that issue? Do we have a chance that this is going to be fixed in the near future?
Sorry to bother you with that, but we have a project depending on aurelia-flux that is currently on hold, because we can not update to the current framework version.
Thanks in advance, Chris
Hi @tfrydrychewicz.
It has been already 2 months since you updated the plugin and responded to issues and I'm starting to have some doubts about future of aurelia-flux. It seems that there are many developers and projects blocked and I think that we deserve one honest boolean answer whether you plan to update and manage flux or not.
Even a negative answers is good one - we could finally move on and replace flux with something else...
In both cases, thank you for the ride. All the best!
this fork seems to at least get my site back up and running ! tkhyn/aurelia-flux
@boxofnotgoodery don't use it yet, for the moment I made 2 or 3 trivial fixes and the DI is not sorted out yet. I'm trying to understand how it's made, and I'll report here if I manage to make it work.
@everybody I did not have enough time to spend on it today but I've started implementing Rob's suggestion to patch the plugin and I'm getting close. I'm quite confident I'll have a working version to review and test within the next few days so stay tuned.
That's really good news! Thank you in advance.
I integrated with aurelia beta version 1.0.0-beta.1.0.1. Welcome to provide comments/suggestions. https://github.com/samlin99/aurelia-flux/releases/tag/v0.1.8
@samlin99 and @everybody, a few hours short but I had already done most of the work on my side (and I have used a slightly different approach). See #22 for comments.
To test it, use github:tkhyn/aurelia-flux@master in your package.json and config.js.
I'll be testing this out tomorrow.. Thank you very much for the work!
@tkhyn Seems to be working out so far! Thanks for the help on this one.
Hi all,
I'm new to Aurelia and desperate to use Aurelia-flux in our new project. Does anyone know if there is a working fork for the latest Aurelia and is this going to be maintained ?
@tfrydrychewicz Any news on the update of your plugin your blog articles in the Aurelia site sold it to me.
@tkhyn Does your fork work with the latest Aurelia?
@EisenbergEffect Since aurelia-flux is very popular, is there a chance that it could become an official part of Aurelia, I think we would all need and love some confidence in its future? PLEASE.
Thanks all
@MMJM I'm not sure if we can commit to aurelia-flux just yet. I would need for someone to point me to a working fork...and then we would need to do a thorough code-review and internal discussion to see if we want to pick this up.
On a related note, Aurelia has always had an EventAggregator for day one. You can use this to accomplish much of the same goals as a flux-based architecture. Our EA supports both string based message channels as well as strongly-typeed pub/sub with class-based message contracts. You can read about it here: http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.8/doc/article/cheat-sheet/10
@EisenbergEffect can you help to review https://github.com/samlin99/aurelia-flux ?
I used my fork one to my company project. Thanks!
I've bookmarked it. I'll try to take a look at it...might be another week before I can get around to it.
@EisenbergEffect thanks for your feedback. I have read more on the event aggregator in Aurelia and am I correct in thinking that apart from the ordering of handlers with the waitfor both are very similar?
BTW many thank to you and the team for the great work with Aurelia.
Yes, that's the primary difference. The EventAggregator is more of a "classic" simple pub/sub system but it gets the job done simpler than Flux architectures in many cases. I usually recommend that developers start with the simple EA first. Then, if something more is needed, you can investigate other options such as Flux.
@MMJM Yes tkhyn/aurelia-flux@master works fine with Aurelia v1b. I'm planning to use it (and therefore keep it in shape to work with Aurelia v1) until I have the time to roll out a Flux implementation that's simpler and more adapted to what I exactly need. Hence I won't commit to support aurelia-flux in the long term.
@samlin99 There are a few things that won't work with your fork. See #22 for the gotchas.
Been using tkhn's branch here just fine (once I got all my coding boo-boo's fixed) I converted back from EA as I like that for maintenance I don't have to worry about subscribing and unsubscribing. It manages that as a convention which is what Aurelia is all about right? :)
Thanks for all the feedback.
Perhaps I should put together something showing how Flux could be built on top of Aurelia's EventAggregator. I think, from the perspective of the core team, that would be ideal. I'd need to think about it...
That sounds like a plan :)
I think probably a lot of us just want something we can rely upon to use in production.
That would be really useful. Even just good documentation around how best to use EA in a non-trivial real world scenario would be good. I hope something like that eventually makes it into the docs.
showing how Flux could be built on top of Aurelia's EventAggregator +1
Hi @tkhyn I noticed what seems to be a bug in your fork. When making multiple concurrent dispatches my team was seeing actions after the first one not being immediately dispatched (seemingly hung). Subsequent dispatch calls dispatch the queued action plus the action(s) currently being dispatched. I haven't had time yet to dig deeper into the problem but wanted to make you aware of the issue!
@tkhyn I have a custom element (component) that uses your fork of aurelia-flux. When using an if binding on the custom element the lifecycle hooks are called. As such the handlers will work initially. Then once the element is removed and readded the handlers are not hooked up again.
Any chance of a fix for that or is aurelia-flux not in use by you anymore? Would it be simple enough?
@iovergard @AdamWillden If you have issues with my fork it'll help a lot to expose them in a minimal sample app. While I can't guarantee I'll fix them that will enable me to quickly see the problem and hopefully fix it easily. You can even open an issue on my fork repo to make the tracking easier.
@tkhyn You don't have an 'issues' tab so I can't open one on your fork
@AdamWillden fixed
Hey kids, looks like this is dead - I suggest either migrating or just in future using Redux with your Aurelia projects, it's framework agnostic and just a state container. I've done a very quick writeup of the process here: https://zen.id.au/using-aurelia-and-redux-together-for-good-times-all-around/
I'm in the process of migrating a medium sized Aurelia project myself.
Hey,
Just dropping in to ask you to update this plugin to match the latest version of the framework. There are a significant number of people using the plugin and it's currently broken, in my understanding. If you don't have time, then please see if you can add an official contributor to help you maintain the plugin.
Thanks, Rob