Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Josh Duff
@TehShrike
so, in that case, you can make that work
you can set up the activate function for that state, and have it listen for events
Andrew Smith
@silentworks
ah I see
Josh Duff
@TehShrike
https://github.com/TehShrike/state-router-example/blob/master/implementations/svelte/login/login.js#L10-L17
That's obviously a BS demo "login" there, but you can do whatever server-touching requests in there
Andrew Smith
@silentworks
yeah which kinda feels like I am rendering Svelte useless and having ASR as an absolute dependency
Josh Duff
@TehShrike
How so? Svelte is great at templating/view
Andrew Smith
@silentworks
because If I change my this.fire to stateRouter.go, I am now relying on ASR to the most absolute form
I would have thought I could fire my normal Svelte events and then hook into those at a parent level
or even global level
Josh Duff
@TehShrike
You can, that's what's happening in my last link there
Andrew Smith
@silentworks
This might be the wrong way I'm going about this
Josh Duff
@TehShrike
https://github.com/TehShrike/state-router-example/blob/master/implementations/svelte/login/Login.html#L21
Andrew Smith
@silentworks
lol
I feel so dumb right now
Josh Duff
@TehShrike
But you'll need to embrace ASR at some point. At the very least, for all of your <a href="{{ asr.makePath('app.topics.tasks', { topicId: topic.id }) }}">etc</a> links
Andrew Smith
@silentworks
I see what you mean now
thats just a helper right?
as in the asr.makePath
Josh Duff
@TehShrike
how do you mean?
Andrew Smith
@silentworks
its just creating the url based on the name rather than an me hardcoding in the absolute path
Josh Duff
@TehShrike
One of the benefits of using ASR is not having to worry about invalid URLs. You should rely on the state name + parameters instead of trying to build/maintain URLs yourself
Andrew Smith
@silentworks
yeah I understand, but its just a helper in that case
a really good helper
Josh Duff
@TehShrike
haha, sure, but in that case all code is a helper
said another way: that function is the canonical way to build a URL to navigate around your ASR-routed app
I usually have two kinds of components in apps like this
the ones that are the actual state templates, that are mounted directly by ASR. These are ASR-aware, and more tied in to the rest of the application. They contain other components which don't directly access ASR, and are more simple view components that emit events
Andrew Smith
@silentworks
cool
I have learnt so much from this
Thanks for all the info you all provided
Josh Duff
@TehShrike
You're welcome!
Andrew Smith
@silentworks
I just notice that passing defaultParamaters to the svelteRenderer can also capture the login event at a global level
Josh Duff
@TehShrike
Do you really want every state to be able to call that method, though?
Andrew Smith
@silentworks
:-)
Not at all, but its just a finding I wasn't aware of
for instance, that would make a good candidate for logout
But hoisting would kill it
So i guess not
Josh Duff
@TehShrike
yeah, for the renderers I've found that it can be handy to allow the coder to hook in frameworky global bits
For logging out, I prefer having a "logout" state that talks to the server in its resolve
So you make the logout happen with state.go('logout') or having the user click on a link <a href="{{ asr.makePath('logout') }}">logout</a>
Andrew Smith
@silentworks
boom
thanks
Josh Duff
@TehShrike
once you get used to driving important changes through the URL, it's glorious
the user never has to worry about reloading the page and ending up in an awkward state
and your views can become closer and closer to pure functions of the url
Gavin Ray
@GavinRay97
@TehShrike If you're around, I wanted to ask you for some quick info
Josh Duff
@TehShrike
wazzaaaaaap
Gavin Ray
@GavinRay97

I posted this in the MobX gitter earlier:

I have a question which may seem sort of stupid.

I am a massive fan of MobX with injected store decorators and observer/observable pattern, it makes sense and deprecates the need the for "state" if you will in components since they're essentially "hot-wired" to the store (global app state).
I've been using state management libraries since Flux was introduced, before Redux ever existed.
I'm curious if there's a way to make an agnostic implementation of MobX that you can configure to work with Vue/React/Angular/Aurelia, etc.

Every time I've used MobX, I've needed (or appeared to need) a "binding" package for that UI framework.
Would it not be possible to write an agnostic implementation that you could pass framework elements or functions into for context?