Yeah. We are using the mentor id and the profile id.
We haven’t merged that PR yet.
1 Like
I updated the wireframes according to design. I know that there might be scenarios that there will be lot to display in prerequisites. Can I know how this prerequisites saves in the DB. Is there a text limit? I mean having lot’s of prerequisites is not good the mentor and for mentees also. @jaye
Apply View:
Edit View:
This is a very good @anjisvj! This is quite enough for this phrase. 
Currently, there’s a no text limit. We can restrict mentors by adding a text limit later, but we need to have a reasonable limit. In most cases, the bigger the better. So, they can well communicate their message with the mentees. In a long run, there’s a possibility to save them DB in markdown. It would be helpful when adding bullets, basic text formatting (Bold, Italic), etc.
Let’s provide a generic message to the text field something like this;
“Provide a GoogleDrive link to a document that contains your resume. The file should be in pdf format. Include any additional information to your document if the mentor has requested any in the prerequisites section. (You can edit this link later)”
P.S.
I’m not a good fan of having a bunch of modals in the app. From the UX perspective, it doesn’t perform well in mobile views. They interrupt the user’s workflow and most of the time it causes users to forget what they were doing. @akshika47 you might have a good explanation for this. This would be not an immediate requirement, what you have implemented is more than enough for the initial level. Let’s discuss how to replace them with some alternatives like having a new page, or subviews, etc.
Thank you very much for your good work @anjisvj! We are always glad to have a team player like you! 
1 Like
As we discussed the reasons for using a modal was,
- If we created an another separate for apply user has to go back always to get to mentors page
- User has to fill only just a one area
I updated the thread and wireframe with new description
To implement this, i think we need a new endpoint to get a mentee. So it can be used to display the ‘edit application modal’ after clicking the edit button
The endpoint i suggest is :
GET /mentors/{id}/mentee
it will return a Mentee object
Shall i add it also to the existing pull request? Or is there any other solution?
WDYT? @YohanAvishke @jaye
1 Like
Thanks, @piumal1999.
I”m confused with your suggestion and your previous reply. What you are referring to here?
Another quick question,
in the mentee list view, if the user has already applied to a mentor, then the apply button should change to edit. The edit button will invoke another API in this case. @anjisvj how you are going to manage it?
I just said that the existing endpoint already works like you said–>
This will return a mentee array right? Because there are more than one mentee for a mentor
I can use program/{id}/mentee/mentors to get the applied mentor. I will use it when the component mount so I can hide the request button with a boolean. @jaye
Cool!
That means we already have the application data, then we don’t need another endpoint to fetch application details individually right? (because we already have that data)
It seems okay for this stage, but when thinking about the long run,
If we do like that, when rendering mentors, we have to go through the application array and check whether an application exists for that mentor. This can be an expensive task. O(n²) (same applied for the programs as well)
But this endpoint only returns the mentor objects. The application data is in the mentee object.
Mentor object:
{
“id”: 1,
“profile”: {
“id”: 1,
“uid”: “”,
“email”: “”,
“firstName”: “”,
“lastName”: “”,
“imageUrl”: “”,
“linkedinUrl”: “”,
“headline”: “”
},
“program”: {
“id”: 1,
“title”: “”,
“headline”: “”,
“imageUrl”: “”,
“landingPageUrl”: “”,
“state”: “”
},
“state”: “”,
“application”: “”,
“prerequisites”: “”
}
This is really good. Thank you @jaye! I will update the thread with the wireframes alongside with the relevant API’s.
1 Like
Here’s the newest wireframes:
- Show all the mentors for the program
- API:
GET: /programs/{id}/mentors
- Apply as a mentee
- API:
POST: /mentors/{id}/mentee
- Show all the applied mentors
- API:
GET: /program/{id}/mentee/mentors
- Show the mentee application
- API:
GET: mentors/{id}/mentee
- Edit the mentee Application
- API:
PUT: /mentors/{id}/mentee/application
2 Likes
Thanks for the reply @piumal1999, I can see some sensitive information in the payload, such as: email, application, profile uid. We need to remove them.
Here, these three API’s related to the same thing
- POST: /mentors/{id}/mentee
- GET: mentors/{id}/mentee
- PUT: /mentors/{id}/mentee/application
The PUT API’s path also should be PUT: /mentors/{id}/mentee/ right?
The following seems missing in the wireframes,
- The profile image
- ink to the LinkedIn profile (Linking it to the name might confusing. Since it is a different platform, better to link separately)
- Headline in the profile cards.
Also, better if we could add a button and hide the form.
This is awesome!
Ah yeah. But i think it will be more clear if we use that /application part. We used a similar path to edit mentor application also.
I’m having this routing issue when mounting the apply form, here’s the draft PR.
1 Like
I’ve added some comments to the PR.
Btw, Did you manage to fix the routing issue?
Nope. Couldn’t find the issue. 
Can you describe the issue?
1 Like