Great Place to Work!

Weeks 2&3

(learning and implementing React, reviewing codes, reporting bugs…)

Sejal Khatri
Dec 26, 2016 · 4 min read

[My Outreachy Project: To improve the Wiki Ed Dashboard’s user profile pages. Mentors: Sage Ross and Jonathan Morgan]

Next task of my project was to start developing with React — a JavaScript library for building user interfaces, So I decided to first solve React based Issue as a simpler learning curve. It dealt with replacing JavaScript window prompt by React confirm window. Sage shared some helpful links and then I started reading more into React and Flux — Application Architecture for Building User Interfaces.

Pair Programming

It is an agile software development technique in which two programmers work together at one workstation. If you haven’t tried Pair Programming than I would suggest you to try it and let me know how it goes for you. I have pair programming sessions with Sage sometimes and can say it’s a productive way of developing software and effective learning.

Session1 motto: To write RSpec tests for the conditional display of Email ID in the user profile pages — I learned about — allow(controller).to receive(:current_user).and_return(admin) FactoryGirl functionality where you can test the output depending on the user. So if you want to check the UI when current user is admin then you just return admin, if regular user then return user and expect response body to render accordingly.(plz correct me if anything mentioned is wrong:)

Session2 motto: Add functionality to Confirm component — I had done changes in the actions component and replaced the JS prompt by Confirm component, then sage joined me to work on updating the confirm component to handle user input. Sage shared a new concept — Conditional Rendering in React: rendering elements conditionally in react depending on the state of application.

Few things I learned:

  • The value read from the element in react component can’t directly be set as this.state.value_key, for that onChange() function needs to be called to set the state using setState({ _valuekey: value }) and now it can be used by react components.
  • Also, you have to initialize that state and that’s why it’s necessary to write the getInitialState() function which returns null value.
  • The state of one component can’t directly be used in another component, you have to pass it as a parameter in a function and then you can use it.

Design discussion with Jonathan

J-Mo(that’s what we call Jonathan) suggested few changes in the mockups I had proposed, he gave some inputs like — no need for the More Info paragraph section in the Profile pages(unnecessary data disclosure). We can have specific form fields which say Why Am I interested in contributing to Wikipedia? And others. I have few things to discuss with Sage on this — his views on what data should actually be there and who will be able to see it.

Things J-Mo reminded me of in our 1st talk :

  • Always ask why you are adding a component to the UI!
  • Why is it necessary?
  • Think from the user’s perspective.

Server Side Testing in Wiki Ed Dashboard.

Wiki Ed Dashboard uses RSpec for unit tests (model and controller specs, and specs for plain old Ruby object) along with extension libraries like FactoryGirl and Capybara.

RSpec by default deals with requests like get and post, it does not have JS support and modern website is full of JavaScripts. So Wiki Ed Dashboard uses Capybara to simulate browser requests with HTTP and FactoryGirl to automate model entry creation.

Code Review

I did my 1st Code Review on GitHub, I realized that you don’t need to be a pro to review an experienced developers code, you just have to understand what’s happening and ask the developer if you have any doubts. Let the developer know if you find anything confusing or have a better simplified way to do the same thing. Sage suggested I should review codes often, and it has really helped me to understand the codebase and coding conventions better.

Bug Reporting

When I was working with another React Issue, I had to write test for that in Mocha(framework for testing front-end utilities and React.js components). Wiki Ed Dashboard uses gulp-mocha(a thin wrapper around Mocha which runs mocha tests) and that is where I found this bug. The next step was to properly document the issue, so as to increase the probability of someone solving it. I took final reviews from Sage on the initial draft and then reported my 1st GitHub issue(yay!)


These 2 Weeks I have enjoyed my work more than ever and that feel continues. Now I actually can’t wait for scrum meetups and listen to what others are working on, which enhances my knowledge and encourages me to perform better. Sage added me as a member in Wiki Education Foundation, I am excited to be a part of this amazing organization full of fun & smart people to work with and having happy to help attitude every time.(Thanks!)

Sejal Khatri

Written by

User Researcher| UX Designer | Information Architect — Actively seeking internship opportunities @ United States https://www.sejalkhatri.com/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade