Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 06 14:14

    dependabot[bot] on npm_and_yarn

    (compare)

  • Oct 06 14:14
    dependabot[bot] closed #47
  • Oct 06 14:14
    dependabot[bot] commented #47
  • Oct 06 14:14
    dependabot[bot] labeled #62
  • Oct 06 14:14
    dependabot[bot] opened #62
  • Oct 06 14:14

    dependabot[bot] on npm_and_yarn

    Bump url-parse from 1.4.4 to 1.… (compare)

  • Sep 29 17:45
    dependabot[bot] labeled #61
  • Sep 29 17:45
    dependabot[bot] opened #61
  • Sep 29 17:45

    dependabot[bot] on npm_and_yarn

    Bump i from 0.3.5 to 0.3.7 in /… (compare)

  • Sep 03 00:51

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 03 00:51
    dependabot[bot] closed #36
  • Sep 03 00:51
    dependabot[bot] commented #36
  • Sep 03 00:51
    dependabot[bot] labeled #60
  • Sep 03 00:51
    dependabot[bot] opened #60
  • Sep 03 00:51

    dependabot[bot] on npm_and_yarn

    Bump immer from 2.1.5 to 9.0.6 … (compare)

  • Aug 12 04:31
    dependabot[bot] labeled #59
  • Aug 12 04:31
    dependabot[bot] opened #59
  • Aug 12 04:31

    dependabot[bot] on npm_and_yarn

    Bump path-parse from 1.0.6 to 1… (compare)

  • Aug 11 00:49
    dependabot[bot] labeled #58
  • Aug 11 00:49
    dependabot[bot] opened #58
Jean-Jacques Dubray
@jdubray
I would argue the Model should know about the States either, it is the role of the state function to notify the "learners" by whichever mechanism
Edward Mulraney
@edmulraney
so we should present an intention: ADD_TODO and the state function should compute a status: TODO_ADDED,
Jean-Jacques Dubray
@jdubray
In general I would say yes, though in this case, it would be hard for the state function to "compute" that value, the model would have to give a hint.
Let's say there is another state which could be "too_much_todos"
that would be computed by the state function
Edward Mulraney
@edmulraney
sure
Jean-Jacques Dubray
@jdubray
the model should not know much about what you do with the list of todos
Edward Mulraney
@edmulraney
so in my app's state function, how can i work out if a todo was sucessfully added ?
Jean-Jacques Dubray
@jdubray
the model would have to keep track of that value
Edward Mulraney
@edmulraney
i suppose i'd have to track last_added_id, vs latest(id)
Jean-Jacques Dubray
@jdubray
that state cannot be computed
but that would mean the state function is stateful
it's better to keep it stateless
Edward Mulraney
@edmulraney
last_added_id would be in the model
Jean-Jacques Dubray
@jdubray
yes
Edward Mulraney
@edmulraney
making it stateless
Edward Mulraney
@edmulraney
conceptually, how would i debounce sam actions? say i have list of users, clicking a user tries to fetch their details, the user clicks like mad on lots of usernames - i want to ignore all but the last request
must be similar concept to action cancelling or throttling
Jean-Jacques Dubray
@jdubray
One way to do it is to issue an action instance id for each action triggered, then present that value to the model, no state is rendered (you might use a different present method for that).
then you only accept a proposal from the last action instance.
would that work for you?
Edward Mulraney
@edmulraney
would i need to store the promise in the model so i can cancel it?
does nap belong before render or after render?
Edward Mulraney
@edmulraney
what are the implications of performing async in the model instead of actions? it seems like the model semantically should be responsible for performing the required work
Jean-Jacques Dubray
@jdubray
Not that I can think of
In general the async you want to do in the model are "fire and forget" (no impact on the state representation, just the application state)
You can also re-render in case of error.
Sorry, my answer is a bit messy
Edward Mulraney
@edmulraney
so fetch users list for example - fire, store, forget ?
Jean-Jacques Dubray
@jdubray
No, reads fit well in the actions
not in the model
Edward Mulraney
@edmulraney
but then we end up with a broken action system
Jean-Jacques Dubray
@jdubray
Updates typically belongs to "next-action" but you have two choices
Edward Mulraney
@edmulraney
one behaviour for synchronous actions, another behaviour for asynchronous
Jean-Jacques Dubray
@jdubray
1/ synchronous update
2/ asynch update with a second render (it is equivalent to next-action / present)

To answer your question,

one behaviour for synchronous actions, another behaviour for asynchronous

no, it works in both cases

because it does not matter when the proposal is passed to the model
There is no requirement for this proposal to occur synchronously or asynchrously
of course you have to be careful that the "state" is such that the action can be triggered and the proposal can still be accepted
but there is no requirement on the action
Edward Mulraney
@edmulraney

lets take our understanding of the two types of action:

sychronous:

function incrementCounter() {
  present({type: "INCREMENT_COUNTER"})
}

asynchronous:

function fetchUsers() {
  present({type: "FETCH_USERS_REQUESTED"})
  ajax.get("http://asdf.com/users")
    .then(users => present({type: "FETCH_USERS_SUCCEEDED", users}))
    .catch(error => present({type: "FETCH_USERS_FAILED", error}))
}

if we wanted a consistent API we could make incrementCounter like this:

function incrementCounter() {
  present({type: "INCREMENT_COUNTER_REQUESTED"})
  modelAccessor.get("counter").set(counter => counter + 1)
    .then(users => present({type: "INCREMENT_COUNTER_SUCCEEDED"}))
    .catch(error => present({type: "INCREMENT_COUNTER_FAILED", error}))
}
Jean-Jacques Dubray
@jdubray
in general you don't need to keep track of what the action is doing
Edward Mulraney
@edmulraney
the two incrementCounter approaches have larger implications on the architecture, but we're okay with doing this for api calls for some reason?
Jean-Jacques Dubray
@jdubray
To debouce you could do something like that:
function fetchUsers() {
  present({type: "FETCH_USERS_REQUESTED", instanceId: newInstanceId()})
  ajax.get("http://asdf.com/users")
    .then(users => present({type: "FETCH_USERS_SUCCEEDED", users}))
    .catch(error => present({type: "FETCH_USERS_FAILED", error}))
}
Edward Mulraney
@edmulraney
how would that debounce?
what does the handler look like?
Jean-Jacques Dubray
@jdubray
In general, I would prefer the action to never access the model
Edward Mulraney
@edmulraney
agreed - but its interesting what happens when you compare approaches to actions
Jean-Jacques Dubray
@jdubray
In the model you would only accept the proposal that has the latest instanceId
sorry, forgot to add the instanceId to the second proposal