GSOC 2020 at Elastic
August 24, 2020
This summer, I got an opportunity to take part in Google Summer Of Code. I got selected as a student developer at Elastic.
My journey to Elastic
This is the second time I’m applying for GSoC. I sent proposals to three organizations last year, but none of them were accepted. It helped me understand my mistakes and prepare well this time. I went through the organizations and found Elastic. Going through the projects of Elastic, I found the best project for me.
Before writing the proposal, I started researching the project. That helped me in identifying the problems of the current system. I also went through all the possible solutions to find the best one. After I decided on the solution, I started writing my proposal describing all the features and issues of the new system. At the same time, I started contributing to EUI solving some good first issues for understanding the codebase. When I was confident, I shared my proposal with my mentors. They reviewed my proposal and gave me some good suggestions.
Now the only thing for me is to wait. In the meantime, I contributed to EUI solving some more issues. Finally, the result came, and I was selected.
Getting started with EUI
The Elastic UI Framework (EUI) is a collection of React UI components for quickly building user interfaces at Elastic.
My GSoC project with EUI was to improve the documentation for typescript components. EUI used react-docgen to extract information from React components. EUI also used a custom babel plugin for supporting typescript. The issue with react-docgen is that it does not fully support typescript components. So a better documentation system based on typescript types was necessary.
Working on the Automatic Documentation System project
GSoC started with a Community Bonding period in May. It all started with a video call with my mentors. They shared their ideas and suggestions about the project. During this period, I was able to develop a concrete plan for the project based on the guidance of my mentors.
My proposal includes the use of a third-party library react-docgen-typescript. It can extract documentation information for typescript componenents. The only thing I should do now was to add this information to React components. So that they can be accessible for showing in the documentation website.
The Babel plugin
The best way I could think was to create a babel plugin. I discussed the approach with my mentors, and they supported the same.
The babel plugin injects the information from react-docgen-typescript to React Components. They are now accessible as a property of the React Component. But, the plugin increased the build time of project from less than 3 minutes to greater than 45 minutes.
Cooper: Well, this little maneuver’s gonna cost us 51 years!
After some research, I came up with a different approach. I can re-use the typescript program used by the plugin. It avoids some overheads. So the build time reduces to less than 4 minutes.
The children prop issue
The type and required properties for children prop was not generated correctly by react-docgen-typescript. For components whose type extending FunctionComponent, the type of children prop comes from PropsWithChildren. A custom interface can’t override this.
Finding components that are FunctionComponent and have children prop. Traversing their AST to find the children’s prop type from the interfaces. Replacing them with the results generated by react-docgen-typescript solved the issue.
Interfaces to objects
The documentation page also expects type information from interfaces. As typescript strips type information, there is no way to get them in the output.
The initial solution I came up with is to create a dummy component. This component extends all the required interfaces. The react-docgen-typescript provides the required information about this component. It has an issue if duplicate props are there in two interfaces, it will process only one of them. This will result in loss of information. Also creating extra components is an overhead.
The next solution I came up with was to convert those typescript interfaces and types to object nodes. Appending these nodes to the source file provides the required information. My proposal was about a babel plugin that does this work. My mentors suggested that a more optimal way is to use a webpack loader. So the loader’s output provides the required information. In that case, the loader’s output only contains the required objects.
What I gained from this experience
For me, GSoC was a great learning opportunity. It helped me improve my knowledge. My mentors showed me more accurate ways to solve several issues. I was able to write cleaner and readable code than before. Also, I learned how organizations maintain an opensource project. The way developers work together in delivering solutions that benefit the community.
I feel lucky to have my mentors Greg Thompson (@thompsongl), Chandler Prall (@chandlerprall) and Dave Snider (@snide). They were providing incredible support during the entire GSoC journey. Despite their busy schedule, they always managed to help me whenever I was stuck. Special thanks to Caroline Horn (@cchaos), Elizabet Oliveira (@miukimiu), Philip Krenn (@xeraa), Aravind Putrevu (@aravindputrevu) and the outstanding eui team for accepting me as a Student Developer.