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

Status of project #3

Open
jiangts opened this issue Dec 30, 2016 · 3 comments
Open

Status of project #3

jiangts opened this issue Dec 30, 2016 · 3 comments

Comments

@jiangts
Copy link

jiangts commented Dec 30, 2016

Thanks for writing this library and giving your talk!

I'm wondering if this is still being actively maintained, and if there are any gotchas to beware of.

So far, I've noticed in
examples/QuantumCalc/src/quantumcalc/statechart/main.cljs it states that bubbling from concurrent states needs to be fixed, and in
src/nodename/stately/chart.cljs there are multiple instances of ;; TODO invoke directly.

I'm not altogether sure what to make of these comments. Perhaps these problems were fixed but accidentally left in?

@nodename
Copy link
Owner

Hi,
No, sorry, those are still to be done.
The "invoke directly" todos are not crucial, just a performance thing. The other, frankly I don't remember, because I have been doing "other things" recently. I was using stately in production on a project that has since been terminated, and it is likely that I will be porting it to Swift in 2017. At that time I will address any problems. The main thing that I want to complete is making it fully independent of re-frame.
Of course I would have to pay attention sooner if someone actually tries it out...

@jiangts
Copy link
Author

jiangts commented Dec 31, 2016

aha. I've been reading the the code a bit and realized the "invoke directly" dispatches were fine.

curious why you want to make it re-frame independent though. I'm considering introducing it to a re-frame app I currently have in production, and have been altering some of the stately.comms calls to reflect the new re-frame api. Do you need it in a project outside of re-frame?

Also curious how your experience was using statecharts for UI development. I'm quite new to it but the talk was pretty provoking. Wondering if you've found them useful in more traditional UI components (lists, trees, forms, video players), and if there are any workarounds to address in UIs that are not as heavily state driven as a calculator :)

@nodename
Copy link
Owner

nodename commented Jan 1, 2017

I want to make it re-frame independent so I can use it in Swift on iOS. The re-frame implementation should remain in place though. If you PR the re-frame api updates I'd be happy to incorporate them.

We were working on a re-frame and React Native version of our app, and (setting aside the fact that it was just too early for RN to do what we needed) Stately was excellent at orchestrating our screen transitions. I'm not sure it would be appropriate for the lower-level UI elements. I don't remember if I mentioned in the talk that statecharts are more of a top-down development approach, in contrast to the usual Clojure bottom-up style.

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