Connect profile API

[0mkara]

• check if a profile exists
• if not show register
• if exists show login/delete
• create profile on register screen
• PUT user info into profile
• navigate to dashboard

[karalabe]

Could you please attach a few screenshots? Would be easier to discuss general directions if I could glimps without having to build and deploy everything.

[0mkara]

1. Login simply means if you already have created a profile continue with that profile data.
2. Delete that profile data with the delete button
   

[0mkara]

3. If no profile already exists show register button on welcome screen
4. Register button takes us to Signup page
5. Create user button creates a profile and PUT user data in it
   

Hope we are following the API till here.

[karalabe]

I've been thinking about this PR for a bit, but all in all I'm a bit wary of the general methodology. The original UI I made was a PoC to have an idea of what's needed, but since then those were evolved a bit in #1. Would be nice to take those discussions into consideration too, otherwise we'll have two diverging idea sets.

Re this PR a few issues I mentioned before in #11 (comment):

• There is no such notion as logging in. Once you have a user, there's absolutely no purpose for the welcome screen to appear, just straight head over to the dashboard.
• User deletion would probably need to land on some user status update / profile page. That I have not created myself but there's a sample one in Mock UI - Lorem Ipsum #1. I do get it that you wanted to expose the functionality somewhere, but there's no point to place a button somewhere that will be discarded anyway.
• In the REST API I've already changed that there's no first and last name, rather just one name, so that is also a bit incompatible.

A general issue that I'm afraid of with this PR is that it kind of hacks in network requests, handling and whatnot all together. Yes, it's good for a fast PoC, but I won't be able to maintain such a code base.

I kind of feel that the approach @daodesigner is taking in #12 is a bit more elegant, as the network requests are completely separate from rendering. I'm also more of a building from the ground up person.

The correct approach I think would be to define the screens that are needed and then go about implementing them. Since @daodesigner started defining them, it might make sense to collaborate (or build the bases for that) than to try and make the current UI work, which will be dropped either way.

[0mkara]

I just checked PR #12. I completely agree with your decision. I would like @daodesigner to continue the design implementations. I will keep an eye on further development there. Let's continue the discussion on PR #12 and let me see what I can do there. 👍