===Profile Information
Name: Dalia Nahol
IRC nickname on Freenode: dnahol
Web Profile: [[ https://github.com/dnahol | github.com/dnahol ]]
Resume: [[ https://drive.google.com/file/d/1ce8Eg2cQysiYEPGXdziB-OLoq8FOmC1I/view?usp=sharing | See PDF ]]
Location (country or state): Santa Clara, California, USA
Typical working hours (include your timezone): 9:00 - 21:00 PST (-8 UTC)
===Synopsis
T233243 Convert all the Campaign and Program pages to React
Currently, the design of the campaigns view is very similar to the courses view for an individual course, but for courses, all the tabs (Home, Articles, etc) are rendered client-side in React, due to which we're not able to add features.
Moving to single-architecture would improve user experience as they can easily navigate from tab to tab, preserving data between tabs after initial render, so that the page feels faster.
Campaign pages will be nicer, and the architecture more consistent, if we use React pretty much everywhere and get progressively closer to a single-page app. Moreover, it will enable the filtering of the courses/campaigns, sorting courses into related campaigns or allow actions on multiple courses of a campaign at once to improve the user experience or the Dashboard.
This involves converting:
Campaign overview
Campaign course tab
Campaign articles tab
Campaign user tab
and eventually all campaign tabs from haml to react
- Possible Mentor(s): @Ragesoss
- Have you contacted your mentors already?
I have contacted mentors via IRC and Slack
===Deliverables Timeline
[Creating Task, Will edit more ASAP]
Describe the timeline of your work with deadlines and milestones, broken down week by week. Make sure to include time you are planning to allocate for investigation, coding, deploying, testing and documentation:
I discovered this Wikimedia Dashboard late in the Outreachy application process, as I had been focused on Mozilla Multi-Account Containers and Facebook Container. I am using the coming days in November to acquainted with this codebase, project direction, and contribute to as many issues as I can.
## Nov 4 M
- Discovered Wikimedia Dashboard Project: Convert Campaign pages to React
- Installed Environment
- Started work on first issue #1088: https://github.com/WikiEducationFoundation/WikiEduDashboard/issue/1088
## Nov 5 T, Outreachy Application Deadline
- Submitted Outreachy Application
- Contacted @Ragesoss via IRC
- Joined Wikimedia Slack, got up to speed
- Continued work on first issue #1088
## Nov 6 W - Nov 8 F
- First PR, for issue #1088: https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3472
- Create Proposal and Timeline on Phabricator
## Nov 9 S - Nov 10 Su
- Edit and finalize Timeline on Phabricator
- Take in any feedback for PR #3472, make any necessary changes
- Choose and start work on 2nd issue
## Nov 11 M Week
- Finish 2nd issue. Make any necessary changes based on feedback
- Start and finish 3rd, 4th, and 5th + issue. Make necessary changes based on feedback
- Work on a more complex issue. Preferably one related to the internship project
## Nov 18 M Week
- Work on and solve as many project-related issues as possible before internship start
## Nov 25 M Week
- Work on and solve as many project-related issues as possible before internship start
## Dec 2 M (Week 1 of Internship)
### Overall direction and timeline, Campaign Overview direction and first iteration
- Discuss tasks, timeline, and priorities with mentors for whole internship project
- Discuss tasks, timeline, and priorities for converting Campaign Overview to React
- Address any foreseen barriers for converting Campaign Overview to React
- Start and finish converting Campaign Overview to React
## Dec 9 M (Week 2 of Internship)
### Set Campaign Course direction and first iteration, Campaign Overview polish
- Discuss tasks, timeline, and priorities for converting Campaign Course to React
- Address any foreseen barriers for converting Campaign Course to React
- Start and finish converting Campaign Course to React
- Fix issues arising from Campaign Overview
## Dec 16 M (Week 3 of Internship)
### Set Campaign Articles direction and first iteration, Campaign Course polish
- Discuss tasks, timeline, and priorities for converting Campaign Articles to React
- Address any foreseen barriers for converting Campaign Articles to React
- Start and finish converting Campaign Articles to React
- Fix issues arising from Campaign Course
## Dec 23 M (Week 4a of Internship)
### Set Campaign User direction
- Discuss tasks, timeline, and priorities for converting Campaign User to React
- Address any foreseen barriers for converting Campaign User to React
## Dec 24 T - W Dec 25 Christmas Family time
## Dec 26 Th (Week 4b of Internship)
### Campaign User conversion, Campaign Articles polish,
- Start converting Campaign User to React
- Fix issues arising from Campaign Articles
## Dec 30 M (Week 5a of Internship)
### Campaign User conversion
- Continue converting Campaign User to React
## Dec 31 T - W Jan 1 New Year Family time
## Jan 2 Th (Week 5b of Internship)
### Finish Campaign User conversion, Feature addition discussion
- Finish converting Campaign User to React
- Discuss Features to be added (sorting, filtering, etc)
## Jan 6 M (Week 6 of Internship)
### Features
- Start adding features
- Discuss and adjust feature priorities and timeline
## Jan 13 M (Week 7 of Internship)
### Start ORES, Feature polish
- Discuss and understand Campaign ORES tab function and data flow
- Start converting ORES tab to React
- Find realistic timeline for ORES tab conversion to REACT
- Feature polish
## Jan 20 M - Jan 21 T Family Event
## Jan 22 W (Week 8 of Internship)
### Campaign Alerts
- Discuss, start, and finish Alerts tab conversion
## Jan 27 M (Week 9 of Internship)
### Set direction for next 5 weeks
- Discuss ORES tab finish and obstacles
- Discuss any other unfinished conversions
- Discuss any priority features yet to add
- Work on first priority
## Feb 3 M (Week 10 of Internship)
### Fix bugs
## Feb 10 M (Week 11 of Internship)
### Finish ORES tab
## Feb 17 M (Week 12 of Internship)
### Finish Features
## Feb 24 M - Feb 26 W (Week 13a of Internship)
### Finish Features
## Feb 27 Th Family Event
## Feb 28 F - Mar 3 Tu (Week 13b of Internship)
### Tying up loose ends
===Participation
Describe how you plan to communicate progress and ask for help, where you plan to publish your source code, etc
===About Me
Tell us about a few:
- Your education (completed or in progress)
A. B. Sociology, Environmental Studies, Princeton 2011
Self-taught Software Engineer
Previously held positions:
Freelance Web Development Consultant
Software Engineer at Flippable.org
- How did you hear about this program?
I heard about Outreachy via a peer in an algorithms and data structures meetup.
- Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?
I plan on being completely focused on this internship with these dates as exceptions for family time:
Dec 24, 25, 31
Jan 1, 20, 21
February 27
- We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?
No, I am not a student and thus am not eligible for Google Summer of Code.
- What does making this project happen mean to you?
It would be an invaluable experience and I would thrilled to have the privilege of making this project happen. It would be immensely satisfying to me both professionally in my journey as a developer and personally as a user and admirer of Wikimedia.
===Past Experience
#### Describe any relevant projects that you've worked on previously and what knowledge you gained from working on them.
I have included descriptions and links to 5 of my apps.
1. PeopleAnalytics | Web App Code Challenge for a startup | 2019
GitHub readme with screenshots and repo: https://github.com/dnahol/PeopleAnalytics
● Project using Ruby and data visualization tools
2. Software Engineer | Flippable.org | San Jose, CA 2017
Screen Shot of the UI I built:
https://angel.co/projects/545935-elections-platform-for-flippable-org?src=user_profile
● Constructed frontend views for Elections product launch utilizing JavaScript, AngularJS and Pug (Jade), reducing traffic to Node.js backend by ~80% through following single-page application design
● Designed 5+ mockups for countrywide candidate engagement platform with HTML5, CSS3, and Google Material Design which greatly improved political engagement in less visible elections by 75%
● Maintained 100% accuracy of district, candidate, and election information and consistency of asset platform content through configuring and maintaining AWS S3 buckets
● Followed agile development practices on team of 10 - 15 with Git for version control for rapid feature iteration
● Refactored navigation system into carousel-based design using JavaScript, AngularJS, HTML5 and CSS3, achieving responsiveness across 5+ major browsers and devices
3. SayCheese | Software Engineer | Collaborative 2018
Mobile camera app
GitHub readme with screenshots and repo:
https://github.com/EspressoTime/SayCheese/blob/master/README.md
● Won Google Flutter and Women Who Code Hackathon 3rd place
● Designed and created an app to play a sound at the instant before picture is taken so small children or pets will look at the camera
4. Kill Your Demons | Software Engineer | Individual 2018
Mobile meditation game on iPhone and Android
GitHub readme with screenshots and repo: https://github.com/dnahol/KillYourDemons/blob/master/README.md
● Designed and created cross-platform (Android and iPhone) mobile game using Google Flutter
● Used open source API Spritewidget as a game engine
● Presented playable game demo at Bay Area Women in Games event and received positive reviews
5. PokéChess | Software Engineer | Collaborative 2016
GitHub readme with screenshots and repo:
https://github.com/dnahol/PokeChess/blob/master/README.md
Web-based two-player competition of wits, speed, and catching Pokémon
● Enabled head-to-head play utilizing Node.js, WebSockets and OpenTok API backend integration
● Built secure authentication system with JavaScript, storing encrypted passwords consistently across sessions
#### Describe any open source projects you have contributed to as a user and contributor (include links).
My open source contributions include the Girl Develop It national website, FreeCodeCamp.org, Mozilla Multi-Account Containers, Mozilla Facebook Container, and WikiEdu Dashboard.
[[ https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Adnahol | Pull Requests on Github ]]
#### If you have already written a feature or bugfix for a Wikimedia technology such as MediaWiki, link to it here; we will give strong preference to candidates who have done so.
Contribution #1: started Nov. 13, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/1744
Issue #1744 four-byte emoji article titles cause MySQL errors
This isn't a direct PR, as I cannot directly access the Wikimedia database. But I did research the MySQL documentation to find some possible solutions, partially tested them locally, and posted them with screenshots and links. One of the mentors and I have been in conversation about this. On Nov 21, the mentor said they found the process I posted useful, tried some of it out on the database, and got some things to work that hadn't worked before. But they are not confident enough with it yet to try it out in production. They said they need more exploration and testing on it.
Contribution #2: started Nov. 19, 2019. Not accepted or merged (yet). Update accepted date by editing this contribution.
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3516
[In Progress]
What this PR does:
Fixes #3515 Article Finder Row buttons not toggling
Affects behavior in #3506 Article Finder: refactor UNSAFE react methods
File changed:
app/assets/javascripts/components/article_finder/article_finder.jsx
Open questions and concerns:
(Received feedback from mentors on these concerns and am using it to address them)
`language` and `project` search fields:
Had to remove language and project search fields to get results from searching this.props.assignments array. This seems to produce the desired result in some tests but I still have to find a way to include these fields in the cases when they are present and needed.
STUDENT_ROLE:
Still need to test the fix in the STUDENT_ROLE case and adjust accordingly.
Contribution #3: started Nov. 16, 2019. Not accepted or merged (yet). Update accepted date by editing this contribution.
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3506
[Awaiting Approval]
What this PR does:
One of several PRs coming to address Issue #3478 Refactor componentWillMount and componentWillReceiveProps
Refactored any files in app/assets/javascripts/components/article_finder
to use the new react lifecycle react methods and stop using soon-to-be-deprecated UNSAFE_ react methods
This refactor uncovers two bugs in Article Finder:
- Loading state of buttons was getting stuck in `disabled` mode. This PR fixes that.
- New Issue, filed as #3515 Article Finder Row buttons not toggling, address by my PR #3516.
Note:
Larger refactor in app/assets/javascripts/components/article_finder/article_finder_row.jsx.
Entirely removed UNSAFE_componentWillReceiveProps
and replaced custom async function wrapped around an await
which sets state.isLoading once await is resolved
Why this change?
The new React lifecycle method to help replace UNSAFE_componentWillReceiveProps is getDerivedStateFromProps. However, the React documentation strongly advises against using getDerivedStateFromProps if it can be avoided, as it makes the whole component and whole app more complicated.
This is what I did to avoid using getDerivedStateFromProps:
In this component, UNSAFE_componentWillReceiveProps was used to update state.isLoading once a change in assignment is loaded. So I wrote a custom async function to do assignment updates and also update the update state as a side effect, once the await that stores the response resolves.
Contribution #4: started Nov. 14, 2019, merged Nov. 18, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3498
What this PR does:
Refactored UNSAFE react methods.
Refactored any files in app/assets/javascripts/components/activity
to use the new react lifecycle react methods and stop using soon-to-be-deprecated UNSAFE_ react methods.
One of several PRs coming to address Issue #3478 Refactor componentWillMount and componentWillReceiveProps.
Got rid of chunks of code in app/assets/javascripts/components/activity/activity_table.jsx.
Entirely removed UNSAFE_componentWillReceiveProps
and replaced instances of this.state.activity with this.props.activity
Why the big change?
Use of UNSAFE_componentWillReceiveProps was only being used to keep state.activity matching props.activity. Since activity was already a prop, there was no need to keep state.activity as well. The React documentation calls it an "anti-pattern" that makes the application more bloated than necessary.
Contribution #5: started Nov. 14, 2019, merged Nov. 15, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3497
What this PR does:
Refactored UNSAFE react methods with new lifecycle in Categories component.
Refactored any files in app/assets/javascripts/components/categories
to use the new react lifecycle react methods and stop using soon-to-be-deprecated UNSAFE_ react methods.
One of several PRs coming to address Issue #3478 Refactor componentWillMount and componentWillReceiveProps.
Contribution #6: started Nov. 14, 2019, merged Nov. 15, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3496
What this PR does:
One of several PRs coming to address Issue #3478 Refactor componentWillMount and componentWillReceiveProps
Refactored any files in app/assets/javascripts/components/alerts
to use the new react lifecycle react methods and stop using soon-to-be-deprecated UNSAFE_ react methods.
Contribution #7: started Nov. 14, 2019, merged Nov. 15, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3494
What this PR does:
One of several PRs coming to address Issue #3478 Refactor componentWillMount and componentWillReceiveProps
Refactored any files in app/assets/javascripts/components/nav
to use the new react lifecycle react methods and stop using soon-to-be-deprecated UNSAFE_ react methods.
Contribution #8: started Nov. 13, 2019, merged Nov. 18, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3483
What this PR does:
As explained in Issue #3482 Loading element in diff_viewer should take up whole table width
Change requested by mentor, Sage Ross, after previous PR #3472:
"One way to improve it a little more will be to handle the Loading state better. After this change, the loading animation includes a border, which is a little distracting.... Ideally, the loading animation should span the entire DiffViewer element instead of just the left portion."
After this change, the diff table width in diff viewer is set to 100% so that the Loading element animation can take up the full width of the diff table.
Contribution #9: started Nov. 4, 2019, merged Nov. 13, 2019
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3472
What this PR does:
- Addresses issue #1088 Diff Viewer shows only one column, on left, if all changes are new paragraphs
- Fixes a bug within the diff table
- Begins to address issue #3478 Refactor componentWillMount and componentWillReceiveProps
Files changed:
app/assets/javascripts/components/revisions/diff_viewer.jsx
34 files, renamed componentWillMount and componentWillReceiveProps to UNSAFE_
Add ref to diff:
The Dangerously Set HTML from the Wikipedia Diff URL did not previously have a ref. I added one, including a setDiff method for it.
Resize empty diff column:
When the table cells, td elements, are empty, they previously lost their width. This is what was causing issue #1088. This PR sets the first empty cell to 50% width in the table, so that both (-) and (+) columns can take up half the table width.
Wrap Loading and (-) diff marker elements in tbody:
There were previously errors caused by the and (-) diff marker elements because they were within a table without being wrapped in tbody. This PR wraps both in tbody, tr, and td, fixing the errors.