by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 06 2017 22:35
    pluma closed #4
  • Oct 06 2017 22:35
    pluma closed #5
  • Oct 06 2017 22:35
    Travis pluma0/fynx (master) canceled (120)
  • Oct 06 2017 22:35

    pluma on master

    Update README.md (compare)

  • Oct 06 2017 22:34

    pluma on master

    Update README.md (compare)

  • Mar 09 2016 17:42
    kristianmandrup closed #20
  • Mar 09 2016 17:42
    kristianmandrup commented #20
  • Mar 09 2016 17:28
    kristianmandrup opened #20
  • Aug 17 2015 00:06
    Travis foss-haas/fynx (v2.0.0-alpha7) passed (119)
  • Aug 17 2015 00:02

    pluma on v2.0.0-alpha7

    (compare)

  • Aug 17 2015 00:02

    pluma on master

    Handle nonexistant stores in co… 2.0.0-alpha7 (compare)

  • Aug 16 2015 22:43
    Travis foss-haas/fynx (v2.0.0-alpha6) passed (117)
  • Aug 16 2015 22:39

    pluma on v2.0.0-alpha6

    (compare)

  • Aug 16 2015 22:39

    pluma on master

    Fixed createCollection export. 2.0.0-alpha6 (compare)

  • Aug 13 2015 21:33
    Travis foss-haas/fynx (v2.0.0-alpha5) passed (115)
  • Aug 13 2015 21:29

    pluma on v2.0.0-alpha5

    (compare)

  • Aug 13 2015 21:29

    pluma on master

    Fixed collection.fromJSON. 2.0.0-alpha5 (compare)

  • Aug 13 2015 21:26
    Travis foss-haas/fynx (v2.0.0-alpha4) passed (113)
  • Aug 13 2015 21:22

    pluma on v2.0.0-alpha4

    (compare)

  • Aug 13 2015 21:22

    pluma on master

    Added fromJSON. Rebuilt. 2.0.0-alpha4 (compare)

Bryan Larsen
@bryanlarsen
var actionsFor = {};
exports.actionsFor = function(id) {
  if (actionsFor[id]) return actionsFor[id];
  actionsFor[id] = Fynx.createActions([
    'foo',
  ]);
  actionsFor[id].foo.listen(function(data) {
    actions.foo({id: id, data: data});
  });
  return actionsFor[id];
};
it does seem like a bunch of extra boilerplate (especially when I simplify like I've done). It may make more sense to pass store={this.state.store().get(id)} actions={actions} context={{id: id}} and have a convention on how you pass context into actions
If Fynx actions would have supported multiple parameters on an action, I probably would have gone for that approach.
This approach definitely has some advantages -- this approach means I don't have to change components when the store changes.
Terin Stock
@terinjokes
i don't think i would pass actions down, instead attach event handlers to pure components
Bryan Larsen
@bryanlarsen
they're basically the same thing, IMO. Instead of passing action={actionsFor[id])} I could pass foo={this.foo.bind(this, id)} or whatever.
the difference is that I centralize my business logic, which has advantages and disadvantages
Terin Stock
@terinjokes
i believe we agree, with a slightly different implementation. all is good in the world
Bryan Larsen
@bryanlarsen
but you've centralized your business logic too -- in the top level actions
I've just also centralized my boilerplate
not much of a win for that. :)
Terin Stock
@terinjokes
ok, some things are good in the world. :)
Alan Plum
@pluma
@terinjokes interesting. Why do you create actions for each ID? You could just pass in an object if you need to pass in more than one argument.
Or something like callback={data => actions.foo({id: this.props.id, data: data}) instead of callback={actionsFor(this.props.id).foo}
I rarely find the need to pass on more than one action at a time, though.
Terin Stock
@terinjokes
pluma: i don't pass actions at all
Bryan Larsen
@bryanlarsen
really? My claimsStore has 11 actions. 9 of them are used by the ClaimEditPage, 7 of them in the ItemsTab, 5 of them in the ClaimItem component, which contains a few components which generally use 3 actions. This last level of component then calls generic components like Input's and Buttons. It's only at the interface above Input and Button that I pass events instead of actions.
And I consider this a fairly simple app.
Seth Nickell
@snickell
Is there a good pattern for performing "transactions" on a fynx store?
I have a series of changes which need to be made all-at-once / atomically or the store ends up in an invalid state.
In particular, I'm using a cursor store, in case that makes any difference.
I'm considering performing the changes in an Immutable withMutations call... that seems like the update would be necessarily atomic. But not sure if there are any unexpected gotchas with this approach.
Denny Trebbin
@fibric
i can think of creating an merge_action_store and wire up all foreign store actions via awaitcalls. what is the root source of needing such merging store actions to happen?
i mean it sounds like you are trying to do a clean up call
Alan Plum
@pluma
@snickell if withMutations behaves as expected, that should be sufficient. You could add a listener to the store that notifies you when its value changes and then see whether using withMutations only updates it once as expected or for once for each modification within the function.
Bryan Larsen
@bryanlarsen
withMutations caused multiple updates when I tried it. I switched from the cursor store to the simple store to avoid this problem.
Nate Wienert
@natew
withMutations has worked for me in the past
Martin Brochhaus
@mbrochh
Hi all. Is there any repo with an example of fynx usage?
I can't wrap my head around the code snippets in the readme (they dont' state what should be saved in which file and what imports are necessary)
Martin Brochhaus
@mbrochh
Hmm I guess I somehow got it working with the SimpleStore
Matt
@mbrookes
Hmm... Looking at the commit history, either fynx has been deemed comlete (unlikely) or the project has been abandoned (or at best is in hiatus. @natew - curious about the choice of flux library for reapp in that case....
Martin Brochhaus
@mbrochh
Damn, really? I just jumped into using Fynx.. was that a mistake?
But then again, how much should a Flux implementation do anyways? It's rather simple stuff, isn't it?
Alan Plum
@pluma
Yeah, it's on hiatus. Sorry about the silence. I'm currently caught up in a few deadlines, but will try to show it more love ASAP. The project it was written for is still active and growing, it's mostly a matter of refactoring.
It won't be abandoned in the foreseeable future, though.
Martin Brochhaus
@mbrochh
great to hear :)
Matt
@mbrookes

Okay, good to know. So how might I apply this to my current architecture, which in simple terms looks like this:

Screen Shot 2015-04-25 at 10.05.08.png

User actions that change data update the database, any changes to the DB cause this.state.data to be updated (using setState() ) which in turn triggers a view refresh (blue section).

Within a view, user actions can change state directly, potentially updating the view, although some sate is just variables (red section). Some actions can trigger changes to both the database, and to local state (arrow from blue section to red).

I'm not currently using any flux library, or dispatcher, just listen for database changes and push the db to state.
Alan Plum
@pluma
In case anybody's interested, here's some dream code for isomorphic routing in 2.0: https://gist.github.com/pluma/510d377688f339241425
Any feedback is welcome.
Alan Plum
@pluma
Hm... now that react-router supports server-side rendering and async routes, I can probably just use that for routing. Would reduce the maintenance overhead and scope considerably. I have to give it a spin and see whether it's as hacky as I fear or actually isomorphically awesome.
Terin Stock
@terinjokes
@pluma pretty much agree that routing should be outside of fynx
Alan Plum
@pluma
@terinjokes I'm going to keep it outside fynx either way. Not everybody will want to use the same router and if I'm not going with react-router the router will likely work without React too.
@terinjokes I've looked into react-router a bit and the handling of invalid but well-formed routes (e.g. /user/1234 matching /user/:userId even if the user ID does not exist) as well as the matching strategy (source order, first match wins) may prove to be incompatible with the project we're developing Fynx for.
Basically they're mixing routing with React views, which I don't really agree with. Most notably because it makes it more difficult to make the code truly isomorphic and re-introduces the problem of external dependencies (like stores currently are in Fynx 1).
Alan Plum
@pluma
I've extracted the router as a separate module and am continuing it's development at https://github.com/foss-haas/rotunda -- it's general purpose and works fine without React or anything else related to Fynx, though we'll be using it internally with React and Fynx. I'll probably restrict the scope of Fynx itself to stores and actions.
Terin Stock
@terinjokes
@pluma that awesome awesome, taking a look now
Alan Plum
@pluma
@terinjokes the router is mostly done, I think. It's still missing a number of tests and some documentation but the logic is pretty much complete.
Bryan Larsen
@bryanlarsen
Is anybody using fynx with react-native?
ryd0rz
@ryd0rz
no, but we are using fynx with reapp