FCC - twitch viewer IV

Day 5

Up at 05:30 to get on with this before the child is up. I think that says a lot about the power of knowing where you are and being in full flow.

So I have logo and whatnot pulling successfully from the API. I need to write another api call that checks whether the user is streaming. I guess actually I need to use that to update the data store then re-render the whole thing. So its should actually be called before the init render.

06:47

OK! generalised the api call to accept a second argument that goes toward formulating the API query url. This means I can call getUserData with a parameter as the second arg and get back whatever I want.

This is the first point when I’m not satisfied with my code cleanliness. I ought to compose separate functions for getting the initial user data and then the stream updates. Instead I’m relying on an if statement to update either the data.accounts array or write data[user] properties for offline/game-in-progress.

I’m also not happy about having the data in two different ‘domains’ in the data object, but cannot articulate exactly why.

Next to update the render method to show users by filter and display their game in progress if online.

07:08

Looking at my current implementation and thinking about approach, I reckon I need to make a new controller function which looks at data.currentFilter and generates a subset of the data.accounts object.

This is then passed to view.render(array) which can also access data.accounts to read the game in progress. Because the array will only consist of the filtered results it can consult this store from within the loop.

Does this violate the MVC by having the view.render method consult the model directly?

BREAK FOR CHILDCARE

15:55

I have hacked away for another hour or so this afternooon. It’s been pretty successful in terms of getting things to work: I have added an onclick handler applyFilter that updates data.currentFilter with the relevant online status, then calls view.render() to display iterate over the relevant subset of users and display the results.

Adding view.clear() as part of that process was trivial, and I got the _js template tweaked so it displays the appropriate status.

Where it’s gotten poor and unwieldy is that I didn’t trust my instincts earlier and store properties of user accounts in key-pair objects under data. This has made my filtering WET and, I fear, the whole edifice brittle.

AND I’ve realised I overlooked a user story at the outset that requires me to handle non-existent (or defunct) accounts. Bleh.

I also need to come up with a way to handle the icons I’ve chosen to represent streaming vs offline.

So, a bit of a re-write is in order. I’m thinking keep all user account data in an an object like:

accounts: {
    name : { 
        displayName: 'display_name',
        avatar: 'logo', // set to a default for non-existent or unpopulated
        bio: 'bio',
        status: 'online',

etc