ChatCraft Advenures #14: ChakraUI Troubles, My First Revert, and Final Recap

ChatCraft Release 2.0

ChatCraft Release 2.0 is available here. It was a pleasure working with everyone during this semester. It's amazing to see how many new features, enhancements, and bugfixes have been added with each weekly milestone. I encourage everyone reading to check out ChatCraft yourself if you haven't already. No API key is required! You can use free providers on ChatCraft today!

Pull Requests

My first code reversion

In last week's blog post, I wrote about a Pull Request I made to fix a toast error bug on ChatCraft mobile. It turns out my code in that PR introduced a number of bugs described in this Issue.

I initially tried adding new code to fix this Issue, but there were a number of bugs my code introduced, so I figured the best move was to revert the commit.

How to revert a commit

You can revert a commit in two ways:

• from the GitHub UI
• from the command line

Reverting a commit from the GitHub UI is straight-forward, and is what I ended up doing. However, my class instructor, Dave, taught me how to do it from the command line:

git checkout main
git checkout -b <topic-branch-name>
git revert <git-sha>
git push origin <topic-branch-name>

You can then make a Pull Request for <topic-branch-name>, noting that it's a Revert PR along with an explanation.

The reversion is done in git revert, which inverses a commit's diff:

• removes added lines
• adds removed lines

Doing this from a topic branch (non-main branch) isn't necessary but it is strongly recommended. This is because while projects will let you land changes directly on the main branch, doing so will often skip any CI (Continuous Integration).

My reversion was simple, but I think that's because of a few reasons:

• my changes were small (affected only 1 file)
• my PR commit(s) was/were squashed into one commit
• the reversion was made before additional changes to the file were made

I have a feeling that if any of these things were not the case, I would have had a harder time reverting my changes.

Backing out a change

This is the first time I've reverted code from a project. Dave tells me that in software projects, this is often referred to as "backing out a change". It sounds a lot more strategic than "reverting a PR", but I think that's because it really is. If the code remained, ChatCraft would produce a lot of bugs in production, and would affect users and developers. In fact, it was better to revert the code now than later when new code is added to the file.

Reverting a commit is not the end of the world. You can always re-implement a fix or feature later, which is what I ended up doing. Just don't forget to provide an explanation for the revert in your PR, and don't forget to re-open any issues that the revert will affect.

Add mobile-specific error toast custom width

This is a version of my original implementation that doesn't introduce any of the bugs the original introduced.

It's essentially the same code I initially added, a custom containerStyle property for ChakraUI's Toast component:

    containerStyle: {
      width: isMobile ? "90vw" : "initial",
    }

Location, location, location

Here's what that code looked like in my initial PR (introduced bugs):

export function useAlert() {
  const isMobile = useMobileBreakpoint();
  const toast = useToast({
    containerStyle: {
      width: isMobile ? "90vw" : "initial",
    },
  });

And here's how that code looks in my new PR (no bugs introduced):

  const error = useCallback(
    ({ id, title, message }: AlertArguments) =>
      toast({
        // ...
        containerStyle: {
          width: isMobile ? "90vw" : "initial",
        },
      }),
    [toast, isMobile]
  );

useToast() vs toast()

In the use-alert.ts file, the properties for each toast message (info, error, success, warning) is defined in their individual useCallback's. In my original PR, I added the containerStyle code to the useToast() call instead because I wanted to avoid duplicate code.

I haven't figured out why, but adding the containerStyle code in the useToast() call introduced various bugs, while adding it in the toast() call within the error useCallback didn't introduce any bugs.

I hope any ChakraUI experts reading can help me understand what's happening.

Issues

/import fails on YouTube videos with no captions

ChatCraft has a cool /import command, which will take a URL and import text. One way you can use the /import command is to use it with a YouTube video URL, and if the video has captions, ChatCraft will return the captions in a message:

Shared Chat Available here

However, I once tried it with a music video with no lyrics, like https://www.youtube.com/watch?v=TKfS5zVfGBc and saw this error toast:

When testing the command locally, I found this error in the backend:

I found a similar error when trying the /import command on another music video with non-English captions available:

Now that we know what the issues are, I think I can make error toast message more descriptive for these edge cases.

OSD700 Recap

Below is a recap of my experience working on ChatCraft and my experience taking OSD700 at Seneca Polytechnic (formerly Seneca College) this semester.

Comparison to Previous Open Source Work

Having finished this course, I noticed a number of differences between my past open source work and contributing to ChatCraft. Some of these are differences in experience, while others are things unique to ChatCraft or unique to my open source class.

1-2 PRs in other projects vs multiple PRs in ChatCraft

In my previous open source class, I made 1-2 Pull Requests to various open source projects. Though I was able to contribute code, my understanding of these codebases was limited to the pieces of code I worked on.

In this class, I devoted all of my attention to ChatCraft, and understood more of the codebase by making multiple contributions. Of course, I don't completely understand the entire codebase. There are still many parts of the codebase I either haven't read or don't understand. However, I noticed that by focusing on one project, I naturally read various parts of the code to understand the code I would modify or build upon.

Working on an active project

With my classmates, Dave, and ChatCraft creator Taras also working on ChatCraft, the project became very active, with multiple Pull Requests being made every week. Reviewing Pull Requests was not only another opportunity to read various parts of the codebase, but also an exercise in reading new code.

I found working on such an active project to be a fun experience.
In our last triage meeting, my Dave mentioned how much of a difference it makes to work on an active project. A project with lots of activity gives out a certain kind of energy that encourages people to use and even contribute to the project. There's always new code being added, and the community around the project grows.

I noticed this when working on ChatCraft this semester. With each milestone new features were added that improved the app. As the weeks went by our work attracted more users, and by the end of the semester, developers outside the course began contributing to ChatCraft as well.

Instant vs. non-instant communication

In past projects I've contributed to, the best way to contact the maintainers was often through GitHub, which is non-instant. For ChatCraft, we've been using Discord - an instant messaging app - alongside GitHub. GitHub was still the primary method of communication when reading issues or making/reviewing Pull Requests, but having instant messaging available, through Discord or otherwise, turned out to be a reliable way to reach out to colleagues.

Triage meetings

This is something unique to my open-source class. Every week, the class ran a triage meeting where we discussed showstopper issues/features, confirmed details on sprint/milestone deadlines and feasibility, and made plans for the next sprint/milestone. These meetings would take the entire class time (~2 hours) but in that time we solved a lot of things logistically.

Just over a year ago, I did a co-op placement (internship) in the IT space, albeit in a non-developer role. I remember having daily standup meetings for certain projects, but I don't remember feeling very accomplished during those meetings. Maybe I'd have a different experience as a full-timer, but based on my experience attending triage meetings I think that longer, weekly meetings would be more meaningful than multiple shorter meetings throughout the week.

Sheriff duty

During this semester I was also a 'Code Sheriff' for a couple weeks. I've described my first Sheriff experience in this blog post, but overall I thought it was a fun leadership experience. In my experience, being a code sheriff didn't mean being an 'on-call' who works on every issue or reviews every pull request (though it's good to provide a review when needed). It just meant helping shepherd new code into the project by providing a resource (e.g, finding reviewers for a Pull Request, putting classmates in contact with someone who can help them with a feature or technology).

Secrets management using sops

One thing unique to working on ChatCraft was how we managed secrets (mostly API keys). ChatCraft uses sops to share secrets, and getting access to secrets was a fun experience I wrote about in this blog post. There's still a lot I need to learn about sops, but once I figure out enough I'd like to implement it in my own projects!

My contributions

When I started working on ChatCraft, I wasn't very confident in my web development skills. I took web development courses in school but the concepts didn't stick well. I just enjoyed writing programs in C++ and writing scripts. Because of this, I devoted most of my focus to making bug fixes and enhancements to various parts of the codebase.

I found that with each enhancement or bug fix I did, I understood more of the codebase, and by the third month I was able to add a couple new features. I've listed all of my bug fixes, enhancements, and features below:

Bug Fixes

• Vite Config - Provide Null navigateFallback URL
• Update Slash Command Criteria
• Fix Shared Chat Accessibility from UI
• Fix iframe auto-resize
• Fix margin between HTML preview button and content

Enhancements

• Don't show hints when editing on mobile
• Add Twitter Card metadata to shared chats
• Search bar placeholder text
• Custom width for error toasts on mobile
• Add Eye ReactIcons to API Key field
• Update ChatCraft System Prompt for inline KaTeX

Features

• '/' Keyboard Shortcut
• Add Nomnoml Renderer
• Packaged github-to-sops to PyPI

Regrets

One regret I have is that I didn't take more risk by trying to implement more features. When doing this course I played it safe and mostly contributed to bug fixes and code enhancements. There were some features at the time that I wanted to implement, but I wasn't confident enough to try because I didn't feel familiar enough with the codebase. It was only until halfway through the semester that I felt confident enough to implement larger features, but by then, there weren't enough weeks to fully flesh out a larger feature.

I try not to compare myself to others, but when I look at all the cool features my classmates added, I can't help but feel I should have tried adding at least a couple larger features, instead of seeking comfort in small bugfixes and enhancements. As someone still learning web development, I'm nonetheless proud of the work I did. However, in the future I want to be less risk-averse when it comes to implementing larger features.

How I used ChatCraft

Throughout the course, I mainly used ChatCraft to help me develop ChatCraft. I've listed three use cases, with shared chats, demonstrating how I've used ChatCraft for various aspects of ChatCraft development:

• Fixing Syntax Errors
  • I'm still re-learning React Hooks, and the syntax often eludes me. Here I used ChatCraft to help me wrap part of a useCallBack in an if conditional.

• Finding Enhancements

  • In an enhancement I made for the search bar, I used ChatCraft's image input feature to send a picture of the ChatCraft search bar to OpenAI's gpt-4-vision-preview model for suggestions on improving the search bar's visibility. For this use case, I even modified the System Prompt to tell the LLM it's an expert in UX/UI design:

• Reviewing Pull Requests

  • In this example, I have a shared chat I made when reviewing the UI changes of the Image Input feature.

I've also used ChatCraft to help me learn how to integrate the OpenAI API with the frontend of a class project I'm working on. I'll even be using ChatCraft to help me develop future projects.

With all the new features added, there are a bunch more clever ways you can use ChatCraft. I highly encourage those reading to use ChatCraft today!

My thoughts on OSD700 (Open Source Development II)

OSD700 is course I've been contributing to ChatCraft for, and it's is one of the best courses I've taken, if not the best course in Computer Programming and Analysis at Seneca. The previous courses I've taken in this program gave me the foundation needed to work on ChatCraft, but those courses weren't exciting, and I just wasn't motivated to keep learning. In this course we were given the freedom to help build an actual project that people use, and the tools to figure out how to do it. Before taking the Open Source classes, I wasn't confident enough in my skills to contribute anything. However, after taking OSD600 and OSD700 I've become confident enough to contribute code. Even if there's something I can't fix or implement, I know I'll always be able to find where I can learn something, or find someone who can help. In fact, taking this course has motivated me to give web development another try.

By a stroke of luck

I originally wasn't supposed to take the open source classes.
When I wanted to enroll for the first open source class in Fall, it was full. However, during the first week of that semester I kept looking for open spots, and on a Saturday morning I found an open spot. It was by a stroke of luck I was able to take the open source classes.

From these courses I learned/gained the following:

• proficiency with git
• how to write good issues and make good pull requests
• how to review pull requests
• the 'open source' workflow
• how to make good code contributions (adding to code vs. rewriting someone's code 'your way')
• the confidence to contribute to open source
• code reading skills (reading new codebases, reading new code someone's adding)
• the importance of blogging and building 'in the open'
• a newfound interest in web development

I honestly believe I would be in a very different place, skill-wise, if I didn't take these courses.

Though it's too soon to tell, I'm confident my experiences from these courses will make a lot of difference in my career and personal development. I'd like to thank Taras for letting us contribute to ChatCraft, and Dave for being a great instructor and mentor. I've learned a lot from working with you both on ChatCraft and related projects, and I hope to work with you in the future.

Next Steps

With this blog post, I've finished my last course of the semester and the last semester of my studies. I'll be taking a short break, but after today I'll be on the hunt for software developer jobs.

It's been a little over three years since I went back to school to study software development. Before then I studied to become a chemist, but a number of factors led me to pivot towards software development. Perhaps I can find a career that combines the two, but after my experience this semester, a career in web development sounds exciting.

ChatCraft

As for ChatCraft, I have some Issues I want to close within the next month. I'll have to balance my work on ChatCraft with work on my own projects, my job search, and life, but I think I'll be able to contribute a little while longer. There are some personal projects I want to start working on after I've had some rest, and I think ChatCraft will be very helpful.

Thank you

I think I'll also be blogging for just a while longer, be it about ChatCraft or other projects. Until then, thank you for reading. See you soon.