You can also write the function as an "arrow function" so you don't have to bind it. It would look like:

.filter((thewidget) => {
  if (blah) {
    ...
  }
});

Also, there's a leftover console.log here.

It would be great to have a unit test for that.

Not that I think of it, the available widgets list could be filtered at the Python level in the api_widgets function in hubs/views/api/hub_widget.py. It's currently a function that does not have the hub as an argument, but we could change its route to "/api/hubs/<hub>/available-widgets/" and only send appropriate widgets.

What do you think?

@abompard if you think that would be a better approach :)

I was just going off the fact that the left-right choice was determined in the react JS, so that is where i put this logic too.

in the meantime, just updated the commit to fix the arrow function issue, and the leftover console.log.

Also added unit tests for the widget params verification, and fixed the unit tests that were also failing :)

Okies @abompard!

Have updated the PR to do the api call rather than in the javascript.

You don't need to specify that it's unicode strings here, because of the first line in this file (the from future import)

Same here, no unicode prefix needed.

Cut'n'paste error here, it should be hub_types.

I agree there isn't a strict distinction between what should be handled by the backend and the frontend in this case (well, except for security and information divulgation concerns of course). I went for a fronend-filtering for the position because it made me save one API call if the user wants to add something to one of the columns and then to the other ;-)
It's not the case here, but I agree both would have worked.

thanks @abompard !

I have removed the four unicode u's, and fixed the copypasta error.

@abompard yeah, it is a lot neater i think to do it in the python :)