0

I'm trying to build a contacts list app to teach myself reactjs, and I am learning fluxible now.

1) A new contact is entered. Upon submit, a newContact object is created that holds:

  • firstName
  • lastName
  • email
  • phone1 (can add up to 3 phones)
  • image (right now its just a text field, you can add a URL..)

2) This newContact object is sent as a payload to my createNewContactAction, and dispatcher is "alerted" that a new contact has been made.

3) At this point, ContactStore comes into play.. This is where I am stuck.

I have gotten my object to this point. If I want to save this object to my database, is this where I would do that?

I'm a bit confused as to what to do next. My end goal would be to show all the contacts in a list, so I need to add each new contact somewhere so I can pull all of them.

Can someone point me in the right direction?

  • I know you're using Flux, but if you want to try to avoid that all together and try a different approach to fetch/push data to the server, take a look at https://github.com/heroku/react-refetch. I went through the same struggles you're having and ended up writing this library to keep things simpler and avoid having stores at all. – ryanbrainard Dec 28 '15 at 02:10

3 Answers3

0

I would make a request to the server to save the newContact object before calling the createNewContactAction function. If the save is successful, then you can call the createNewContactAction to store the newContact object in the ContactStore. If it isn't successful, then you can do some error handling.

To understand why I think this pattern is preferable in most cases, imagine that you saved the contact in the store and then tried to save it in the database, but then the attempt to save in the database was unsuccessful for some reason. Now the store and database are out of sync, and you have to undo all of your changes to the store to get them back in sync. Making sure the database save is successful first makes it much easier to keep the store and database in sync.

There are cases where you might want to stash your data in the store before the database, but a user submitting a form with data you want to save in the database likely isn't one of those cases.

Brandon
  • 891
  • 8
  • 11
  • Thanks for the response. If you don't mind, I have a follow up question. In order to make the call to save the object to my database, would I use something like the fluxible fetchr? http://fluxible.io/extensions/data-services.html – Askskd Rieid Dec 27 '15 at 21:38
  • I'm not sure. I actually have never worked with Fluxible or even isomorphic React, so I don't want to steer you wrong on this topic. But my advice about trying to save to the database before storing in the store still stands. – Brandon Dec 28 '15 at 01:53
0

I like to create an additional file to handle my API calls, having all of your xhttp calls in your store can clutter things very quickly. I usually name it with my store, so in this case something like "contacts-api.js". In the api file I export an object with all of the api methods I need. eg using superagent for xhttp requests:

module.exports = {
  createNewContact: function(data, callback) {
    request
      .post('/url')
      .send(data)
      .end(function(res, err) {
        if (callback && typeof callback === 'function') {
          callback(res, err);
        }
      });
  }
}

I usually end up creating 3 actions per request. First one is to trigger the initial request with data, next is a success with the results and last is one for errors.

Your store methods for each action might end up looking something like this:

onCreateNewContactRequest: function(data) {
  api.createNewContact(data, function(res, err) {
    if (err) {
      ContactsActions.createNewContactError(err);
    } else {
      ContactsActions.createNewContactSuccess(res);
    }
  });
},
onCreateNewContactSuccess: function(res) {
  // save data to store
  this.newContact = res;
},
onCreateNewContactError: function(err) {
  // save error to store
  this.error = err;
}
Andrew Axton
  • 1,032
  • 7
  • 9
0

DB calls should ideally be made by action creators. Stores should only contain data.

Atanas Korchev
  • 30,562
  • 8
  • 59
  • 93