User page

[nl0]

User page. Branched off of #313, so shouldn't be merged before it.
@akarve @asah pls review

Questions:

• now the api returns ok response (with empty package list) even if the user doesn't exist -- is it ok or should we check it somehow and show some "user doesn't exist" message?
• should we show something else on the page? task description in asana suggests that there should be "browse all packages" link and gallery, is that right?

[akarve]

@nl0

• for the time being go ahead and handle the error (even if it doesn't occur) e.g. as we do in containers/App/sagas.js in doGetPackage; and make sure the component renders the error condition using the existing classes (e.g. this link for a package that doesn't exist)
• just list the packages for now. page title should be Packages owned by username

[akarve]

@nl0 also, if the list is empty, do something like this. I believe PackageList provides a default string for that (it should, anyway).

[nl0]

@akarve

for the time being go ahead and handle the error (even if it doesn't occur) e.g. as we do in containers/App/sagas.js in doGetPackage; and make sure the component renders the error condition using the existing classes (e.g. this link for a package that doesn't exist)

the error is handled properly on the front-end, but the thing is that the api doesn't return error for the non-existent user, it just returns an empty package list, which doesn't seem correct.

also, if the list is empty, do something like this. I believe PackageList provides a default string for that (it should, anyway).

PackageList already does this (it says "Nothin here yet").

[nl0]

page title should be Packages owned by username

done

[nl0]

i'll rebase this and double-check if everything's ok

[akarve]

@nl0 branch is approved but you'll need to resolve the conflicts before i can merge

[akarve]

BTW - API is behaving as expected; please still test the failure case (status !== 200) and error chain, but for now it's OK if API is 200 even if user doesn't exist.

[nl0]

@akarve ready. As with #302, this PR is incompatible with #326, so if one is merged, the other one should be adjusted before merging.