GSoC 2019: Add edit preview to non release entities MusicBrainz

gsoc
musicbrainz-server
gsoc-2019
Tags: #<Tag:0x00007f8d658f9680> #<Tag:0x00007f8d658f93b0> #<Tag:0x00007f8d658f9220>
#1

Personal information

Name: Anirudh Jain

Nickname: Cyna

IRC nick: Cyna

Musicbrainz userid: anirudhjain75

Email: anirudh.jain@outlook.com

GitHub: https://github.com/anirudhjain75

Twitter: https://twitter.com/Cybercynide

Proposal

Objective

My Objective is to create a preview component that can be used to preview changes above the Edit Note section so the editor/user knows what edits he/she has proposed to be changed for submitting it.

Solution

Using Release editor preview as a reference, I’ve planned on adding previews to order entity types like artists, relationships, events, recordings, etc as requested by MBS-8815.

The last section which is the Edit Note section can be used for previewing the changes as similar to the Edit Note sub-tab in the Release editor. The red bar shows the current state while the green shows the changed value.

The below image shows the layout of the preview of the changes made in the Release Editor and there is also an image which shows the preview of Event Editor

Next is the image of the Non Release Entity Editor

This the after project expectation of the Preview component

My approach to solving this is using React states, I am planning to use local component states in the converted edit_form.tt which will be converted before using preview in them. I plan on using react state hooks as musicbrainz prefer using const over class in React templates. The fields of the editForm.js will have a seperate state so they can be viewed before submitting. I’ll save the current state as a previousState object and then I will use the values that are changed and save then as the editedState. The preview component will take the previousState and editedState as input and return a react component with the preview of the changes as shown in the image above. This component will be modified to work with every edit entity types so instead of having the same code in every file, we will be able to reuse the React Component. As musicbrainz use selenium for testing the UI changes, everytime I edit an entity edit form and embed preview component I will write test for them on Selenium

Bonus Objectives

I also am planning to replace the preview component of Release Editor with my implementation of the preview component as according to MBS-9911 the templates are getting converted from Perl templates to React components.

Community Bonding (May 06 - May 27):

In the community bonding period the main focus will be to get more familiarised with the way everything is orchestrated in musicbrainz-server and understanding more about it from mentors. I might have my exams during this period but I will be active on IRC and making small conversions and fixes to the musicbrainz-server repository. I will be exploring the files that are to be changes and planning how to implement my GSoC project

Here is the weekly breakdown of my goals that I propose

Week 1 and 2 (May 27 - June 09):

  • I’ll begin writing the preview component to make it work with aliases component which is at /root/component/aliases. that includes creating a component and writing the code to preview the difference between two states, It also includes integrating the component into existing code and making sure that the component integrated works as expected and the aliases edit changes are previewed. As this is the first part of the musicbrainz repository I will be modifying I’ll take much time here.

Week 3 (June 10 - June 16):

  • This week I’ll complete the work from the last week, I’ll also spend time figuring out how selenium tests work and write tests for aliases to make sure that when in aliases, alias is added the Edit Preview component is rendered with the right data

Week 4 (June 17 - June 23):

  • Converting edit_form.tt to React for Place Entity type so It can be used with react hooks and the preview component.

First evaluations here

Week 5 (June 24 - June 30):

  • Converting edit_form.tt to React for Series Entity type so It can be used with react hooks and preview component for further work.

Week 6 (July 01 - July 07):

  • This week I’ll work on my preview component and make it work with Place and Series entity type. I’ll also write test on selenium to ensure everything works as expected

Week 7 (July 08 - July 14):

  • After the first evaluation, I’ll continue my work on converting edit_form.tt to React for Work and Release Group entities and test if the React template works as expected.

Week 8 (July 15 - July 21):

  • After my edit form is converted into React template, I’ll embed my preview component into the template and make the necessary changes in the preview component so it renders the changes properties of Work and Release Group entities correctly. After making this changes, I’ll write UI tests on Selenium so everything works the way it should.

Second evaluations here

Week 9 (July 22 - July 28):

  • This week I’ll work on converting the edit_form.tt for the Artist and Recordings entity, making sure it works correctly. I’ll add the support of react hooks in the editForm so state management could be done easily.

Week 10 (July 29 - August 04):

  • After my edit forms are converted to React for Artist and Recordings entity, I’ll embed my preview component in the edit form above the Edit Note section and make changes to my preview component so it works with Artist and Recordings entity. I’ll spend the remaining time writing the UI tests for them on selenium.

Week 11 (August 05 - August 11):

  • This week I’ll work on converting the edit_form.tt for the Event and Label entity, making sure it works correctly. I’ll add the support of react hooks in the editForm so state management could be done easily.

Week 12 (August 12 - August 18):

  • After my edit forms are converted to React for Event and Label entity, I’ll embed my preview component in the edit form above the Edit Note section and make changes to my preview component so it works with Event and Label entity. I’ll spend the remaining time writing the UI tests for them on selenium.

Week 13 (August 18 - August 26):

  • Finalize the project completed for GSoC and work on comments provided by mentors.

Final Evaluation here

At this state, Pretty much everything I have proposed will be completed including the bonus stuff. The user experience while editing entities will improve improving the overall user experience of musicbrianz site

After Summer of Code
Continue working on Musicbrainz. Fixing any bugs if found later.
Hope to contribute in Bookbrainz which is created in React. Apply to become a Google Code-in mentor to help students with the onboarding process

Detailed information about yourself

Tell us about the computer(s) you have available for working on your SoC project!

MacBook Pro Mid 2014

When did you first start programming?

I first started programming when I was in my 11th Grade which is about 4 years from now. I entered into competitive programming and was seleted for INOI 2016 (Indian National Olympiad for Informatics)

What type of music do you listen to?

I listen to Linkin Park, Greenday, Charlie Puth, Alan Walker, Simple Plan, Tool and a few more artists and bands on a random basis

What aspects of the project you're applying for (e.g., MusicBrainz, AcousticBrainz, etc.) interest you the most?

I’m applying at Musicbrainz because the whole convertion from Template toolkit to React interests me. I am able to witness a system using a Perl backend which is the old practice and convertion to React seems to be like baby steps for shifting the tech stack of the system

Have you ever used MusicBrainz to tag your files?

I haven’t used it yet and hope to use in future it I actually have music files stored on my PC. I usually use online music service such as Spotify, Apple Music, Airtel Music and a few more.

Have you contributed to other Open Source projects? If so, which projects and can we see some of your code?

I’ve worked on Zulip (open source chat platform) before and made minor fixes in their repo worked majorly on their mobile app.

If you have not contributed to open source projects, do you have other code we can look at?

I’ve worked on open source projects but you are welcome to checkout my github repository for some of the projects I’ve created

What sorts of programming projects have you done on your own time?

I’ve worked on an Image classifier, an e-commerce app on react native, and a few apps for easing my daily life work. I’ve also worked on Google Actions API to help me with my routine life

How much time do you have available, and how would you plan to use it?

I have a lot of time available, around 6 to 8 hours a day at least. I spend my time working on my data science skills, discussing ideas for potential projects with my potential team mates and work on open source projects if not at least learn about it

Do you plan to have a job or study during the summer in conjunction with Summer of Code?

I don’t plan on having a Job during my summer but I will be working on polishing my skills if its counted as studying

3 Likes
#2

Hi anirudhjain75,

Thanks for the proposal. :slight_smile: I was writing feedback on your earlier version, but then waited for your update.

My Objective is to create a preview component that can be used in form pages where the changes to the form data can be displayed so the editor/user knows what edits he/she has proposed to be changed.

I’ll clarify that MBS-8815 is about edit previews for entities, not just any kind of form or form data (e.g. this wouldn’t make sense on the “Edit Profile” form).

Just pointing out that the objective is vague until you read further.

Using Release editor preview as a reference, I’ve planned on adding previews to order entity types as requested by MBS-8815.

I’m glad you clarified that the focus here is MBS-8815. (In the previous proposal, it wasn’t clear what the focus was.)

The below image shows the layout of the preview of the changes made in the Release Editor

Images are good! But it’d be more effective to show some pics of what it’d look like after, since we already know what it looks like before. :slight_smile:

The image of the “Editing” menu below isn’t useful. In general there are bits of filler like this, which normally I wouldn’t care about, but at the same time information which is actually needed is missing.

My approach to solving this is using React states.

More details are needed here.

Will you use redux to manage the state, as in root/static/scripts/work.js, or store it on some component (which component?). If the latter, can we use hooks to manage state, and would the useReducer hook be a usable alternative to redux?

The previous value of form input can be either saved as another state or could be retrieved by the respective catalyst controller and the values stashed by it.

I don’t follow the retrieved-from-Catalyst idea, since up until here this was assumed to all work on the client-side. When would you need to retrieve it from the server again if the original state is already available once the page loads?

Automated tests will also be added for testing the React Component.

Ideally we’d have some general Selenium tests for the entity edit forms that check the previews, though if you were thinking of additional component-specific tests, some more details would be nice!

The current setup of release preview is created on KnockoutJS framework which might not go well with React Components and as musicbrainz-server is converting all of its templates to React components it would be better to change the implementation of KnockoutJS to a ReactJs implementation.

The release editor uses Knockout for everything, not just previews. However, porting just the previews part to React (and glueing it to the Knockout code) is still possible, and that seems fine as a bonus objective.

This would be one of my bonus work as well as the feature to change layout from sections to tabs and vice-versa. I also plan on creating a preview button which can display the page that is editing with the edits that are proposed so the editor/user can have a glace at the effects his changes make over the page.

I’d remove this from the proposal. It’s far too much work in addition to MBS-8815, and not fleshed out at all.

Here is the weekly breakdown of my goals that I propose

The timeline is concerning to me.

Figure out what all the files have to be editing or added and also complete setting up my laptop for working during the entire Google Summer of Code period.

Ideally you’d have everything set up before GSoC, or at least during the Community Bonding period. But in any case, figuring out what files need to be added or edited is quite vague. I’m not sure that should take up a whole week, or what you’d be doing.

Understand how rendering works in musicbrainz-server.

It’s unclear what you mean by rendering (too vague, again), or why this should take an entire week.

Here I will spend a lot of time thinking about the catalyst context and how to get data from it. Due to this, I’ll be spending more time reading the codebase and designing a solution and less time coding.

With help from a mentor, you should be able to figure out how data is passed around in a few hours at most. Especially since you already converted the admin attributes page for us, you should have some experience with that already.

Convert edit_form.tt to React ( /root/entityType/edit_form.tt )

You have this as a general task for each week, but it’s not stated which entity form you’re focusing on each week.

There’s no mention of which edit types you’ll be converting to React each week.

4 weeks is not enough time to convert all the edit forms and all the edit types.

Second evaluations here

Everything after here is unrealistic and way beyond the scope of MBS-8815, except perhaps integrating the React-based previews into the release editor. (Unfortunately, it wouldn’t allow us to remove Knockout either.)

I’d remove the entity preview idea from the proposal, and use the extra time to flesh out weeks 5-8 more. You should also have extra time from removing the unnecessary padding in weeks 1-4.

4 Likes
#3

Thank you for your feedback. I’ve read them and all of it makes sense. I’ll make the changes and think more about how to distribute the work into weeks. :slight_smile:

1 Like
#4

That should be removed from your proposal.

(you wrote:) “to replace [release editor edits preview] with my own component instead of using Knockout for the same” (bitmap wrote:) “seems fine as a bonus objective”. That means it should not be required for the final evaluation anyhow.

There is a misunderstanding here: bonus stuff is not for final evaluation, it is for potential extension that could be done once everything that is required for final evaluation has been done.

1 Like
#5

Ok, I was thinking the bonus objective is meant to be mentioned on the proposal, Should I remove the bonus objective from the proposal description too ?

#6

If possible, can you help me figure out what to do during week 11 and 12 please

#7

I have more general concerns about the timeline:

  • goal for week 1 seem to be the same as for week 2 (besides tests),
  • goal for week 3 seem to be the same as for week 4 (besides tests),
  • and so on.

You should take more weeks to convert the very first entity type you will convert, rather than trying to convert all entity types at the same pace. That should keep you busy for weeks 11 & 12.

1 Like
#8

The difference between the two weeks are that during the first week, the perl template is being converted to React. and In the second week I’m working on the modifications to the React Code and writing Selenium tests. Ill add the extra two weeks to the preview of first entity type