Open in app

Sign in

Write

Sign in

Let’s Build a Web App! Week 15 out of 30

Rona Chong
7 min readNov 13, 2017

--

In which I wrap up one pull request and make another.

Hey strangers and friends!

Here’s my weekly breakdown for what’s gone down most recently in my web dev journey. It’s Week 15 out of 30 — the halfway point! 😱 I’m working on building Moshimoji, my community-oriented platform for reading, sharing, and publishing manga and other comics.

As you know, I’ve been working on getting an MVP done for a while. This week I mostly worked looking towards a deadline (next Friday) to have my MVP done.

If you DIDN’T know, yet are for some reason here and interested in learning more about what I’m talking about, here are the previous posts for this blog series:

I’ve received some feedback from my friend that these posts of mine get a little jargony. Even though these posts are mostly for my own reflection, I do want it to be general audience-friendly, so I’ll work on paring the technical details down from now on!

What did I set out to do?

Mockups of a few of the modules/views I’m looking to minimally implement for my MVP

To get my MVP done, I have to implement a lot of stuff: basically, basic functionality for all my ‘site modules’, as I’m calling them (user and site dashboard, database, groups, forum, reader, reviews, and site news). Some modules are less important than others, but I still want at least 4 available for the MVP.

Up till now, I’ve been (slowly) working on the user dashboard (adding user statuses), because that was the most convenient thing to test my login functionality. So the first thing in my sights was to fix any remaining bugs with the user status submit and feed and get that pull request done (finally).

After that, I planned on moving on to the next module (either the site news or reader). Didn’t really set that many objectives this time around, just wanted to see how far I could get.

What did I end up getting done?

Fixing any remaining bugs with user status submit and feed (done):

  • Picking up from where I left off last week, I finished following these docs to make sure my Apollo client would be able to parse any GraphQL fragments I used correctly. For some reason I am still get a warning message about using the simple fragment matcher, however.
  • I fixed one or two bugs in my code to update my application cache (Apollo cache) post submission of a new user status, ultimately switching back from the Apollo API’s ‘update’ function to ‘refetchQueries’ and getting it to work again. The main bug was that I wasn’t passing a new value for the query variable in the refetch. This query is a query to my GraphQL server to fetch user statuses stored in my db, by the way.

Finishing up that first PR for moshimoji (done):

  • I saw that my potential pull request still showed a lot of irrelevant files I’ve since moved out of the moshimoji-frontend repo, despite my attempts to clean the git history, so I used git filter-tree to remove the files from the index for real and did a little bit of rebasing.
  • This pull request was way too big so I wrote a summary to get my mentors up to speed (to be sent to my mentors… soon).

Moving on to the next module (in progress):

  • I toyed between working on the reader and working on the site news (which is the root view for moshimoji) and decided to go with the latter since I would have more momentum with (similar features to the dashboard I’ve been working on).
  • Once I thought about the site news module, I realized that my particular idea for how to relate content required me to implement the forum first. Or at least have a solid picture of the data models for the forum, as my site articles would inherit from those.
  • I realized that, judging by my speed so far, hand-coding a forum would be really unfeasible, so I should really look at incorporating other people’s solutions. I spent a bit of time researching and settled on Misago, a well-featured forum which shares my stack (Django backend, React frontend)… though it’s a slightly dicey option since it’s still under a lot of development (when will I learn? 😆)
  • The other thing about Misago is that while it shares my stack, it has a slightly different architectural setup — instead of having the React frontend served by a separate web server in front of the Django backend, the React bundle is instead simply included in Django templates, meaning it’s a React-under-Django sort of deal.
  • I’m writing a lot about this, sorry. After coming up with a plan for how to expose data for Misago to my GraphQL endpoint, I worked on merging the Misago Django project with my existing project, with the bulk of the work being the merging of project configs and switching from SQLite to PostgreSQL. I’m still on config merge step.

One additional task — a pull request to refactor some component code and add login, logout components (done):

  • When I updated databases, I no longer had my previous users and had to logout and relogin. I had implemented a login form which will pop up if you try to navigate to the dashboard and weren’t logged in, but I skipped over the logout. So I went ahead and added login and logout components while refactoring some code.

What went well:

  • For the most part, I worked steadily when I had time, something I’m happy about given my difficulties here and there in the past.
  • I was tired of rewriting similar logic for components which depended on UI state a lot, so I wrote a boilerplate component to make things more DRY and functional. It went a lot more smoothly than I expected!
  • Writing new components that weren’t all too different from previous components I’d written also went quick compared to writing those components the first time around, which I am vastly grateful for.
  • So far, merging the Misago config and my moshimoji config so far hasn’t introduced any breaking changes for the non-Misago side, yesss.

What was difficult:

  • This week I had to balance between working on this project and my search for a new apartment, which I’m wrapping up. It was a good challenge since you will always have to balance between work and life — still, there were one or two days where I mostly didn’t work since I was busy with the rental application and so on.
  • I know that implementing the forum would take me a few days optimistically speaking, judging by how often small hurdles pop up which nonetheless take me a while to figure out. Was it for 1 hour or 1 day that Guillaume told me to try to do something before switching to a simpler solution? Anyway, I don’t have a lot of time left, so I probably have to allow myself only one day to try to implement the forum before giving up and using a mockup of the models my site articles would inherit from. Making that sort of compromise is always (((( ;´Д`)))) for me although I’m trying to be less perfectionist.
  • Looking back on this week and last week, I spent a bit of time cleaning up my git history because my changes got away from me and weren’t tidy for a PR. In the end, I think the PR is too big anyway, so I don’t even intend for my mentors to review it. The difficulty was that I didn’t feel ready to have my code reviewed by others without taking time to ‘polish the code’, yet I didn’t want to slow down for that polishing when I had a lot of ground to cover. So that’s another perfectionist impulse to negotiate.
  • The same thing about not wanting to slow down has applied to reaching out to mentors with questions, but I know that the feedback I can get from my mentors can be really insightful for me!

What I would do differently next time (next time typically meaning from now on :P):

  • Make more incremental pull requests. If I’m worried that there’s more changes I need to add before the code is ‘complete’, I can make a note in the PR or in the code.
  • To reduce the overhead of reaching out to mentors with questions, I would consider using Slack as my platform for communication rather than emails next time around. I feel that it is easier to share questions with multiple mentors at once that way and is a more familiar platform for asking engineering questions, so I would use it more readily.

One cool thing I learned about:

You can make a pull request on a branch which is already up for a pull request on the master, merge it, and then merge the initial pull request. That’s handy if you have to have your pull request reviewed but don’t want to be blocked by that review to continue developing!

Misc links for your browsing pleasure:

React
Misago
GraphQL
Self Improvement
Project Management

--

--

Rona Chong

Written by Rona Chong

89 Followers

(✿◕‿◕)

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams