Double async events



  • This is the first time I've seen this pattern but I find it quite stupid.

    When one of our apps starts we load the metadata for all the content of the home screen. Each metadata item takes a calls to a library ( getProduct("123") & getProductStatus("123") ) and in the end it looks like this:

    {
      id: "123",
      title: "Star Wars",
      status: {
        rented: false,
        free: false,
        expires: 0
      }
    }
    

    That's fine and all. The problem here is that, for some reason, the first call to getProductStatus returns broken data. And this is the expected behavior of the library. What we're supposed to be doing is:

    1. Execute getProduct("123") & getProductStatus("123")
    2. Listen for the status_updated event
    3. Execute getProduct("123") & getProductStatus("123") again after the event is raised
    4. Render

    The code looks like this:

    var self = this;
    lib.on('status_updated', function(){
        self.getProducts(callback_to_render_fn);
    });
    // noop call so cache is filled
    self.getProducts(function(){});
    
    

    This is because, after all the assets have been retrieved, the real call to obtain their statuses is done and the event raised. Oh, well, at least the getProduct function caches the results and there's no performance hit.



  • @Eldelshell said:

    the first call to getProductStatus returns broken data. And this is the expected behavior of the library

    Why? Is there a requirement in the spec "The first call to getProductStatus shall always return junk data to ensure our developers are paying attention" Wouldn't it make more sense to simply fix the library? It shouldn't break existing code unless the bad data is actually valid for something else and is relied on somewhere... :wtf:



  • Exactly, or don't return anything, or an error. :headdesk:



  • Is it obviously broken, like: title: "bla bla bla junk data don't use" or is it subtly broken like rented: true instead of false?

    I mean it sucks either way, but one of those two is better than the other.



  • Subtle as "where are all the movies I rented yesterday?"



  • Yah, yikes. Shitty implementation of "eventual consistency" NoSQL database perhaps? Or just utterly broken cache code?



  • It's a library which wraps a webservice from the client. And I don't want to go in there.



  • You could have callback_to_render_fn point to a function which makes the second call to getProducts() with the actual render function? It's still sucky, but it gets rid of the race condition...


Log in to reply