code-corps / code-corps-ember Goto Github PK

This is the page where a user will add their skills, for example:

Should we be logging users out anytime they hit a 401? Right now I see that when adding a new post, I get logged out of the application if I didn't have permission to do so. This seems unexpected. Not that I should see the form if I didn't have permission. But I'm not sure this is expected behavior.

What do you think @begedin?

We need to create the front-end for creating a comment. Markdown preview would be nice but not necessary.

We need a login form for email/password, add a link for "sign up" to login form, and after signing in, redirect to projects page.

When we apply a filter, it should be reflected in the URL, ex:

• /posts?type=task

We need to design the individual post page.

This is problematic because only certain types of users can create certain types of posts. And we'll need to show the types in a dropdown.

We can't show the same list to everyone, since some people can only submit issues, and some people can submit anything.

Implement the design finished in #8.

Implement the profile edit page designed in #21.

A user should have their skills listed on their profile.

We'll want to use the {{related-skills}} component for this, and pass in the userSkills of the user who's currently viewing the profile (to see the skills they have in common).

This will need an h2 or h3 tag in the component for Skills, and perhaps an ( i ) icon that will say "Skills you share are highlighted" when hovering, in a tooltip.

See #6

A user selects skills they have and should then be able to click "Show me the projects" to get a list of projects that require the skills they have.

This navigates from the skills page to the project page, so it is blocked both by #7 and #9

It will involve either adding a list of skill ids to the projects request, or a user_id as well as changes api-side which would return a list of projects appropriate for the specified user.

@joshsmith What do you think the better approach would be.

The way I see it, filtering by skills would allow us to later implement a skill-based search of projects, while just fetching projects appropriate for the user would make it a simpler request. Are we planning such project searches in the future?

Similar to #53

Currently, only new posts can be added. Existing ones cannot be edited. This should be prerequisite for #56

Logging in successfully should redirect to the projects page.

Once we have both a signup and a login form, the link to the signup route should be moved from the root application template into the login form.

Blocked by #2 and #3

Currently in /settings/profile if a user removes their name/website etc. from the the text box and then clicks update it will erase their previous data.

Not sure what we should be checking for/doing here. For example, we probably want them to be able to remove a website they no longer have access to or user but probably we probably want them to have a name once they add one.
This or at least ask, "Are you sure you want to remove your Name?" if they previously had information and then are setting it to an empty string.

We need to create the post page designed in #15.

This may need to be done on the API but right now the error messages are very user-unfriendly.

For API error wrapping, some research notes:

Ember-Data expects the typical JSON API error format, but there is a difference in how it works with validation, and other errors.

• If the response code is 422 Unprocessable entity, ember data will initialize a DS.InvalidError.
• For any other code, the initialized error will be DS.AdapterError

DS.InvalidError

DS.InvalidError expects the error data to be in the following format (the listed properties are the minimum it needs to have):

{
  errors: [
  {
    detail: "Detailed message"
    source: { pointer: "data/attributes/dasherized-field-name" }
  }
  ...
  ]
}

If the errors are in this format, ember-data's serialization layer will parse them and the model will have its model.errors property set. Note that the model.isError will not be set to true in this case. The model.isError property is only set to true if, during a model.save, the server returns an error that is not a validation error.

The default field name format is dasherized, but my guess is, if we override our serializer to expect underscored property names by default, that setting will also apply to errors.

My proposal is that, for validation errors, we do a PR on the API side which changes how we serialize those errors so the format is valid for ember.

Then, we handle such errors by catching a failed save on the model. We will have access to properties such as model.get('errors.username'); and it will be easy to display them.

Fetching the property in the way I describe will give us back an object:

[
   {
      "attribute": "username",
      "message": "The username is too long"
    }
]

Basically, detail is mapped to message and pointer is mapped (with modification) to attribute.

DS.AdapterError

This instance is used for any other error, including model save errors that aren't validation errors. This type of error expects the format:

errors = [
  {
    title: 'Adapter Error',
    detail: message
  }
]

If the API doesn't return a body with an error response, a default error object will be generated, with a single error in it, with detail set to 'Adapter operation failed'.

There are two additional error classes which are sometimes used - DS.AbortError and DS.TimeoutError. They inherit from DS.AdapterError by initializing it with custom messages of their own.

Basically, I don't really think we should handle errors in any custom way. Ember-data already wraps errors on it's own well enough.

At most, we might want to override the messages ember uses, so we could do a wrapper for that, which checks the error type and returns a different message based on that.

Something like

function overrideErrorMessage(error)
  if error.typeOf(TimeoutError) { 
    error.set('message', 'Our custom message for timeout error');
  } else if (error.typeOf(AbortError) {
    error.set('message', 'Our custom message for abort error');
  }
}

We would likely override the above two, since as far as I can tell, they are raised when the operation fails, but the server doesn't respond with anything.

For an AdapterError, the server did respond with something, so we should leave the message the server provided.

We need to design the page for adding a new post.

We would likely need to do something along the lines of mocking the router in order to achieve this, but it would speed that part up, and provide us with information how to do it in the future, so I think it's worth it.

We need to implement the design finished in #6.

It's deprecated, so we really ought to replace it ASAP.

We could use a general third party component, or something specific for our needs, depending on judgement.

We need to handle username, email, and password. Add a link for login instead to e-mail signup form. And after signing up from the front page, redirect to skill selection.

When you add a comment to a post, that comment is not reflected in the UI. You have to reload to fetch the new comment data.

We need to design a user's profile page, which will include a user's basic information, photo, skills, website, Twitter, and contributions.

Right now I don't believe this is the case.

We need to design a page for users to edit their profile.

• User can edit their photo
• Better spacing on the page
• Ability to edit skills from here

You should be able to click a button in a project to join it. We should flash success (and maybe some sort of popover to really drive home the thanks and give some orientation), and change the button.

We need to have a screen to actually reset your password with the new password (on the tokenized URL).

We'll want to borrow heavily from this: https://github.com/twitter/twitter-text/blob/master/js/twitter-text.js#L643

Closed by #93.

Will probably include markdown rendering

Prerequisite is #17

We need to design the individual project page.

Should look something like:

We need to implement the page designed in #13.

When the password gets reset, we should flash whether an email was successfully sent or not.

Right now the acceptance tests do not fail properly. I think that inserting things into the schema directly like we're doing with Mirage right now is causing an issue where we have false positives on acceptance. In reality, we need to ensure that the route is going through the process of hitting a particular API URL, which I don't believe is happening right now.

We'll need to properly render Markdown in comments (and the post's body, which is also in Markdown).

Here's how this is done:

return filename.substr(filename.lastIndexOf('.')+1)

#34 needs to be merged before this can be done, since there is overlap

We need to implement the profile page designed in #19.

• It should be viewed
• It should be editable
• The API will accept base_64_photo_data, so there is no need to upload. It should suffice to read the photo on the client side and send the bae64 data - blocked by code-corps/code-corps-api#187
• Might be a good idea to limit file size.

Unlike on the API side, routing on the Ember side should be mostly unnested. Nesting routes in Ember means nesting of UI, which is mostly not what we want. An individual post should not be nested inside the list of posts, for example.

Continuation of #16

We need to design the list of projects. We're only starting with one, so we should keep that in mind.

If the number of pages is <= 1, we should not be showing the page controls at all.

For new posts

1. User starts typing
2. Periodically, the post is saved to the API as draft
3. API transforms markdown into html, sets it to post body, returns post with body filled in
4. Ember can show preview using body field in separate tab/pane
5. Once user clicks publish, the final version of the post is saved in the published state

For edited post

1. User clicks edit on existing post
2. Periodically, the post is saved to the API as a separate draft
3. API transforms markdown into html, sets it to post body, returns post with body filled in
4. Ember can show preview using body field in separate tab/pane
5. Once user clicks publish, the original version of the post has changes saved.

Questions

1. What does the API do with the drafts once publish is done - might require issue on API side.
2. How does the API figure out which original post the draft of an edit belongs to? It could be doable by identifying via number, but I'm not sure. There is no unique index on the number field at the moment, so it is possible.

Implement the design finished in #10.