Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
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?

Response: "I bet you there is. Just like how TehShrike made an agnostic version of ui-router. https://gitter.im/TehShrike/abstract-state-router"
I'm wondering whether or not what I'm trying to do is feasible with AST or any other package.
Josh Duff
@TehShrike
The way that ASR integrates with every other library is by way of a custom adapter/renderer for each library: https://github.com/TehShrike/abstract-state-router#current-renderer-implementations
If you use ASR, it's relatively easy to hook up your state solution of choice to every component that gets mounted automatically by ASR when the route changes
Gavin Ray
@GavinRay97
So say with Vue, for example, the main.js typically looks something like this:
import Vue from 'vue';
import App from './App';

new Vue({
  el: '#app',
  template: '<App/>',
  components: { App },
  data: { someGlobalStorePackageOrObject }
});
Josh Duff
@TehShrike
Handling any state library could be tricky, you'd have to define a common language that would let the components communicate out
Gavin Ray
@GavinRay97
import createStateRouter from 'abstract-state-router';
import Vue from 'vue';
import App from './App';

const VueInstance = new Vue({
  el: '#app',
  template: '<App/>',
  components: { App },
  data: { someGlobalStorePackageOrObject }
});
const stateRouter = createStateRouter(makeRenderer, VueInstance)
?
TehShrike/abstract-state-router#114
Josh Duff
@TehShrike
I don't think that pull request is going to go anywhere :-x
Gavin Ray
@GavinRay97
I saw this PR, curious if "Root element can be a function" means I can pass In an instance of a Vue object.
Oh, lmao :joy:
I have written this:
The interesting bit is the /src/store folder
Josh Duff
@TehShrike
import createStateRouter from 'abstract-state-router'
import makeVueStateRenderer from 'vue-state-renderer'
import hookUpStoreToAllRenderedStates from 'library-that-you-could-make'
import reduxOrWhateverAdapter from 'adapter-library-for-library-that-you-could-make'

import App from './App'


const renderer = hookUpStoreToAllRenderedStates(makeVueStateRenderer(), reduxOrWhateverAdapter())
const stateRouter = createStateRouter(renderer)

stateRouter.add({
    name: 'app',
    route: 'app',
    template: App
})