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:- Execute
getProduct("123")
&getProductStatus("123")
- Listen for the
status_updated
event - Execute
getProduct("123")
&getProductStatus("123")
again after the event is raised - 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.
- Execute
-
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...
-
Exactly, or don't return anything, or an error.
-
Is it obviously broken, like:
title: "bla bla bla junk data don't use"
or is it subtly broken likerented: 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 togetProducts()
with the actual render function? It's still sucky, but it gets rid of the race condition...