An Update

I write as I listen to “Our Plague Year“, I sit on the bed I’ve sat on for a week straight.

I left Toronto a week ago, and I don’t think I’ve fully processed the time passing. I still feel like it has only been a week since everything changed so abruptly. You can see this failure by the two week gap between my pull requests. Working on school work has become a bit of a chore, there was some burnout already building up prior to everything happening.

With my routine gone, it is easy to lose track of time.

At least Telescope is something I find worthwhile. It is significantly easier to work on it than all the other assignments. It was jarring nonetheless, to see that two week gap.

So here is what I worked on prior to and after this new world.

Release 0.8 was more of a bug fix release. Making sure things were looking better and getting Telescope to a state where things don’t break too much. It was also one where we tried to do some soul searching for Telescope. One of those goals was more successful than the other.

  • Issue:#853 |PR: #854

    Telescope has a drawer that works now.
    I’m glad that we decided to use material-ui, as I’ve probably mentioned before, it does make creating a working interface much easier.
image
Initial work for drawer

The documentation for material-ui was a great asset. It made adding a drawer a very painless process, and there wasn’t many lines of code that needed to be added to achieve this. Customizing the drawer was the most difficult part, while I got the drawer to an acceptable level, there are still some tweaks I want to work on but will need more research to be able to achieve it.

The documentation I read can be found here, under the Temporary drawer section, and the code to bit of code to achieve the functionality can be read below.

// This code goes outside of the return() along with the other const variables  
const [state, setState] = React.useState({
    right: false,
  });

  const toggleDrawer = (side, open) => event => {
    if (event.type === 'keydown' && (event.key === 'Tab' || event.key === 'Shift')) {
      return;
    }

    setState({ ...state, [side]: open });
  };

  const sideList = side => (
    <div
      className={classes.list}
      role="presentation"
      onClick={toggleDrawer(side, false)}
      onKeyDown={toggleDrawer(side, false)}
    >
      <List>
        <ListItem className={classes.item}>
          <Link to="/search" className={classes.links}>
            Search
          </Link>
        </ListItem>
        <Divider className={classes.line} />
      </List>
    </div>
  );

// This bit of code goes inside the return()
 <Drawer
  classes={{ paper: classes.paper }}
  anchor="right"
  open={state.right}
  nClose={toggleDrawer('right', false)}
 >
 {sideList('right')}
  </Drawer>
  • Issue:#827 |PR: #851

    This pull requests makes sure Telescope has a <title> so the tab can provide more information that simply “https://telescope-dusky.now.sh/&#8221;

    In order to achieve this, I followed GatsbyJS’s documentation about SEO components. While I could have done other things, I felt that at least setting groundwork for SEO information can improve Telescope so it is easier to navigate, faster, and more user-friendly.

    This pull request required some fixes so that we re-used already existing code and so that my debugging console.logs() were removed.

    The documentation I followed can be found here, and the blog starter I used to help me with the layout was the gatsby-starter-default, more specifically the SEO component.

    The code for Telescope was as follows:
import React from 'react';
import PropTypes from 'prop-types';
import Helmet from 'react-helmet';
import useSiteMetadata from '../hooks/use-site-metadata';

function SEO({ description, lang, meta, title }) {
  const siteMetadata = useSiteMetadata();
  const metaDescription = description || siteMetadata.description;

  return (
    <Helmet
      htmlAttributes={{
        lang,
      }}
      title={title}
      titleTemplate={`%s | ${siteMetadata.title}`}
      meta={[
        {
          name: `description`,
          content: metaDescription,
        },
        {
          property: `og:title`,
          content: title,
        },
        {
          property: `og:description`,
          content: metaDescription,
        },
      ].concat(meta)}
    />
  );
}

SEO.defaultProps = {
  lang: `en`,
  meta: [],
  description: ``,
};

SEO.propTypes = {
  description: PropTypes.string,
  lang: PropTypes.string,
  meta: PropTypes.arrayOf(PropTypes.object),
  title: PropTypes.string.isRequired,
};

export default SEO;

I had to add the SEO component to each page we had, and we will have to add the component to every page we make so the Tab can be more informative. But it is a simple <Seo title=”Title” /> so that our tabs are better.

image
image
New and Improved!
  • Issue:#771 |PR: #776

    This is where I removed the famous pants that gave the name to our release. Lots of useless files were removed and as a result the code was cleaned up a bit. No tutorials or documentation to follow this time. Just figuring put what was being used and what was not.
  • Issue:#769 |PR: #777

    This fix revolved how the then-new header looked once logged in. The original fix did not take into consideration login state, so nothing was styled.
image

The fix was mostly CSS and material-ui themes. Currently, I can’t access the logged in site, but my fixes were approved, so I will assume it looks wonderful.

File an issue if it doesn’t.

  • Issue:#804 | PR: #852

    So this is where we find that Telescope soul searching wasn’t as successful. I have not really found how or what should go on the about page, much less how it should be organized. Part of this is a result from some issues that occurred while trying to film a promo for Telescope. Day 1 of filming turned into the the only day of filming. While I try to salvage any footage, I decided to add the page meanwhile. I do not want a repeat of the search bar.

    Components ready to be used but nowhere to put them.

    Now…to make those components…

    I hope that I will be able to get a sort of routine during these uncertain times. I hope I will finish all that I need to, both for telescope and for my other school work. But most of all, I hope I get cake somehow.

A quick recipe for displaying the version number on your site

Issue: #711|PR: #755

Want to let everyone know the current state of your site? Wish to display with both pride, and some level of apology, that you have yet to reach 1.0? Do you want to do it in a way that saves you about 20 seconds every time you deploy?

Then this recipe is for you – no hard-coding and no extra effort on your part.

What you need:

  • A website
    • The one I used runs on React and uses GatsbyJS for more flavour. Results may vary based on your environment
  • A package.json file
    • It should have the version field filled out.
  • A spot where to display the information
    • good places include: In an about page, somewhere in a hamburger menu, the footer, a header, hero banner.
    • Bad places: Haphazardly thrown in anywhere with no styling

Preparation:

  • Go to the component/page where you wish to display the information. Import the package.json file. Feel free to name it whatever you wish, I named it Version. This also works even if the package.json is not in the same folder as your component/page
import Version from './package.json';
  • Now, wherever you wish to display the version number, put this: {Version.version}, making sure to substitute only capital V Version with whatever you named the import.
    This is how my code looks.
<div className="version">v {Version.version}</div>
  • That’s it! You’re done.

Warning: There might be security issues if you use Browserify. For a deeper look into possible issues, go to this link.

(Never) To See The Light Of Day

When I look at my course load, it reads “overloaded”.

When I mention I’m taking 7 courses once again, people’s reaction don’t vary much beyond muttering something along the lines of “it’s insane”. I mean, I get it. If all of my courses were a heavy load, I would think I’d be some kind of hardcore masochist. Reality is, there’s only about 4 courses that take up most of my time at any given time, even if I had taken the acceptable 6, my work load would be similar.

The problem is not the number of classes, but the work in those classes. There are classes which take a lot of my time, but I welcome it as I learn and grow as a developer – my capstone project and open source for example. Then there are classes that take up my time because we need to do work for the sake of work.

Every week I have a 3 hour lecture that consists of answering some questions, such magnificent questions like: What is a lossy file? what are some guidelines for using text? what is a reliable source?

Questions that we already covered previous courses and which get no deeper insight beyond what the first result on google says. This class has labs and assignments with about the same level of depth.

The problem lies, that the busy work tends to take precedence over work I rather be doing (damn due dates), which is how it took me about a month to fix our header for telescope.

I can’t say I’m any good at juggling.

I won’t blame it all on the one…or more than one…class though. I have a habit of ignoring issues I do not know how to approach in favor of doing what I know I can do. Currently I’m prioritizing this blog instead of figuring out how to code a finite state machine. After I post this blog, I will fix more of the front-end. Tomorrow I’ll work on my capstone and study for midterms. Design patterns, what’s that?

Back to the header.

When I first approached the header, it didn’t want to do what I wanted it to do. I also had very little idea of how it was supposed to work, I don’t really use animation or movement in my designs. I have to admit, sometimes kind of cool features require way more code that you bargained for. After a brief time spent with no progress, I moved the fix to the bottom of my priority queue and went off to do more designs for the front end and to figure out how to give everyone a heart attack how to relate my programming experience with duolingo.

Things changed when we decided to use material ui. I had never heard of it before, but I had known about others that did similar things. This event happened to coincide at the same time I needed to do the front-end for my capstone project. I was battling with two nav-bars (I’m tired of calling it a header. I navigate with it) because when you push your problems into the deepest parts of the sea of neglect, they multiply.

I had two nav-bars to do, and making them from scratch did not see very appealing. I had tried react-bootstraps and some other smaller frameworks in my capstone, but I was not having much luck. Some elements weren’t loading, others didn’t let themselves be customized.

So I decided to try material-ui in my capstone, see if I would enjoy using it or at least make my life easier. I did struggle a bit at the beginning, since not everything I needed was downloaded despite me following the tutorial, but eventually I was able to add it.

In the end it wasn’t difficult, and it really did improve the look of the ui. Mind you, it had been nothing but plain text prior to my changes.

Succeeding in that project gave me the confidence to finally tackle the nav-bar in Telescope. It feels great to have a feature no longer be broken. It also feels great not having that issue in the back of my mind. I can finally focus on other issues without feeling like I’m lagging behind, and it feels great to add to the code something more substantial than simply removing an image or changing the background colour.

It’s finally functional!

The code:

const useStyles = makeStyles({
  root: {
    flexGrow: 1,
    backgroundColor: '#242424',
  },
  menuIcon: {
    fontSize: '2.5rem',
  },
  searchIcon: {
    fontSize: '2.5rem',
    color: 'white',
  },
  title: {
    flexGrow: 1,
    marginLeft: '1rem',
    color: '#a4d4ff',
  },
  links: {
    color: 'white',
    fontFamily: 'Roboto, sans-serif',
    textDecoration: 'none',
    fontSize: '1.5rem',
    margin: '0 0.5rem 0 0.5rem',
  },
  button: {
    float: 'right',
    margin: '0 0.5rem 0 0.5rem',
  },
});

const Header = () => {
  const { title } = useSiteMetadata();
  const classes = useStyles();

  return (
    <div>
      <AppBar position="fixed" className={classes.root}>
        <Toolbar>
          <Typography variant="h3" className={classes.title}>
            {title}
          </Typography>
          <IconButton color="inherit" className={classes.button}>
            <Link to="/search">
              <SearchIcon className={classes.searchIcon} />
            </Link>
          </IconButton>
          <Button color="inherit" size="medium" className={classes.button}>
            <Link to="/" className={classes.links}>
              Home
            </Link>
          </Button>
          <Login />
          <IconButton edge="start" color="inherit" aria-label="menu" className={classes.button}>
            <MenuIcon className={classes.menuIcon} />
          </IconButton>
        </Toolbar>
      </AppBar>
    </div>
  );
};

I should add, my rehaul of the nav-bar unintentionally solved an issue I suspect was long forgotten. The previous hamburger menu icon did not display properly, so there was only one pixel you could click that would trigger it.

It’s not a problem anymore! Partially because it can’t be clicked on since my fix….I need to file that issue

All The Small Things For a Better UI

For release 0.7, one of the things I focused on, was to improve the front-end to better reflect the mock-ups I designed, as well as to improve the user experience.

The issues related to that goal weren’t particularly intensive; I’m pretty sure they all had “5-minute-fix” labels on them. However, they would be left with no owner if I didn’t claim them. Telescope does not yet have enough outside contributors that these issues are taken before they get buried. While not program breaking, they do make Telescope look like it is broken and outdated.

A Brief Summary

Issue: #713 Remove starry background | PR: #736

telescope1
This is the background with no fans

With this fix, we say goody-bye to the stars. While a beautiful background, we had to admit it gave Telescope a bit of a 90’s vibe. Looking outdated is not a good thing for a website, while you can say “don’t judge a book by its cover” all day long, the truth is that we make a lot of assumptions based on what we see. We’re visual creatures, we can’t help it.

Here are a few assumptions we make about sites that look outdated:

  • The information is also out of date or unreliable
    • For a site that holds blogs about our current projects, that is not a good look
  • Out of touch with current technology
    • Again, the blogs are about tech. If the site looks like it was made 20 years ago, would the user expect the information provided to be up to date? 20 years is a long time, but even more so when related to tech
  • Don’t have a good understanding of technology
    • The opposite of what we want to convey. Learning is different from ignorance.

Issue: #737 Remove Telescope Logo from under the Hero Banner | PR: #737

Once we added the Hero banner, the logo’s position became an issue. Coupled with a glitchy header, it created a sloppy first impression for new users. It was also an annoyance for old users; the hero banner already prevents an user from immediately reading the blogs, but the logo added an unnecessary obstacle. This gave the impression that we don’t care about the users. Because at the end of the day, if we make something that no one wants to use, what’s the point?

Issue: #720 Create a Search page | PR: #739

This issue I made as a preventive measure. So far, we have just thrown things at the front-end just to have something there. I don’t necessarily mind the approach, but it takes a really long time for any of the features to be fixed so that they are remotely pleasant to look at and pleasant to use. I admit I’m part of the problem, it took me a good month to fix our header, which was a mess and very broken.

So in order to avoid our main page from looking even more broken, I made to search page so we could at least put the components where they needed to go. Sadly, it took a good week to get merged.

So much for not looking broken. Telescope as of 2020-03-01

That does lead me to a problem we have in Telescope – Code reviews. I notice it more on the front-end side as that’s were I work the most and there are less people working on it, but I’m sure it is an issue for everyone. A lot of code sits with 1 or no reviews, or changes requested but no response from the author. I think this is an area we need to improve on as a group because it really blocks the development.

Update:

Managed to fit in another issue before the deadline.

Issue: #756 Style the login button so it fits the other elements in the header | PR: #758

Could I have fixed that button when I fixed the header? yes. But I already delayed the header long enough. While this issue didn’t take long, it very well could have. Besides, the login button was in a completely different component. Better to stick to what I was supposed to fix, than delay any longer.

непредвиденный

Along with with writing and the arts, I have always enjoyed languages. I like the patterns, the similarities, the differences, and the coincidences. During the past summer, I realized it was the first time in two years that I didn’t have anything to do. Four whole months where I could actually work on my hobbies without thinking about deadlines or grades. The perfect time, or so I thought, to give learning a language a shot.

Things got out of hand. Quickly.

To make a long story short, I added way too many languages to my Duolingo app. Among the many, I had Japanese and Russian. They were the only languages I chose that had an alphabet different from the Latin Alphabet, but was my experience with both quite the opposite!

The Japanese module started with you learning hiragana, one of the building blocks of the Japanese writing system. You would learn a character set, words you could make with that set, and then when it came to test your knowledge, you could click on the nice tiles and be done.

Image result for duolingo japanese
Duolingo Japanese Modules

Russian wasn’t like that.

When I decided to do Russian, it threw me right in, with no explanation of the Cyrillic alphabet. There are 33 letters in it, and not many of them sound the way you would expect.

Image result for cyrillic
See the P? It’s not our type of P

I did my best, but it is not easy to write something when you don’t know what each letter sounds like. Unlike the Japanese module, I actually had to type and spell. Which meant I had to get a Russian keyboard for my phone.

Eventually, I realized I could only get so far. Sure, I could wing certain words, auto-correct saved me a couple of times, but there was a lot of fundamental knowledge that I was missing. The more words I learned, the harder it was to remember them all. The more I tried to move forward, I would be stopped because I could not spell.

It was the realization that made me give up on Duolingo. That, and the fact it made the process into one about gaining points. Learning and understanding become secondary when there’s a number you need to gain.

You might be reading this, wondering what it has to do with my progress with Telescope, and well…

Much like I lack the Russian fundamentals, I lack the fundamentals of a big part of web development. I’m currently at a place where I am stuck, hacking away hoping something sticks. Up until recently, I dealt with problems everyone else had dealt with because they had been problems in our assignments. Now, working with Telescope, and all the stuff it interacts with, you can’t really go to stack overflow and find an answer.

It feels difficult asking for help, since I feel that I should know a lot of what I don’t. It doesn’t help that the more the project grows, the more daunting it becomes to learn. I didn’t exactly set myself up for success either, since I signed myself up to work on a complicated, for me, area in my capstone project for my first milestone. Too much research to do, too little time.

My first issue and pull request for 0.6 were very easy; adding a react version to the eslintrc file.

PR: Added react version to eslintrc file | Issue: React Version Warning

What I did:

  1. Added settings to the eslintrc file that specify the React version to
  2. Prevents the warning about React version not being specified

The code:

settings: {
    react: {
      version: require('./package.json').dependencies.react,
    },
  },

Where I got the fix:

Warning: React version not specified in eslint-plugin-react settings

My second pull request wasn’t.

Issues: Add static route to serve new GatsbyJS frontend | Add building frontend for staging and production deployment

Pull Request: Point / to the gatsby public folder

At first my issue was that my machine could not run docker. Well, it can, it just takes a toll. I can only have VSCode and one firefox tab open at the same time. Usually, when I’m coding, there are at least 7 tabs. It didn’t help that my capstone also had a milestone going on at the same time, and that I was working on the frontend. I couldn’t do all of them at the same time, and I tend to push projects to the side when I don’t feel confident.

Eventually I realized I could work on what I was doing without Docker – my capstone milestone was passed, Telescope’s design was frozen – so no more excuses. I read a lot, but it was more to rule out stuff than anything else. At the end, I ended up adding this code to the Gatsby side of things.

What this code does, its to create a proxy on localhost:3000, where our server is, and process requests.

My problem arose from the fact that I could only successful point the server to the public folder, which only appears once you build gatsby, which was not what we wanted. We wanted to be able to see the changes made to the frontend in development mode immediately. No matter how much I researched, I couldn’t find anything. I also didn’t know if I should change any of the routes or if I needed to make my own. This was probably my first time looking at Telescope’s server, and I’m still not quite sure at what a lot of it does.

Eventually, we decided to just point to the public folder and have docker build Gatsby automatically. I also added that code, with a lot of help from David and Josue, which you can see below.

This was my first time dealing with Docker, which was interesting.

Going forward, I want to do more work implementing the frontend. I feel that I will be able to work on more issues that way. I also have a better understanding and a better base, which will free up my time to review more pull requests. I feel like I need to do more reviews, and I’m often too busy working on my own issues to do reviews.

Despite the difficulty, I’m glad I decided to continue working on Telescope. The benefit of deadlines and grades, is that you need to do work. And in order to get things to work, sometimes you need to learn. At I’m still trying with web dev, even if the same can’t be said about Russian.

Speaking of Russians, turns out that while we were working hard for release 0.6, Telescope suffered an attack from a Russian and Ukrainian IP. Can’t say I expected that.

2020/01 Collection: Working on Telescope

Prologue

“Something just flashes into your mind, so exciting, and you must out with it. If you stop to think it over, you spoil it all.”

L.M. Montgomery

I spent my three weeks off deliberating whether to take the class following DPS909. On the one hand, I enjoyed the experience it gave me…on the other, there weren’t a lot of projects I was interested in working on. While localization helped me last semester, it took a while to get pull requests accepted and there weren’t that many projects that I could find that still required Spanish translations.

Additionally, there isn’t really a way to improve the quality of my requests, other than through volume…and I have my limit when it comes to editing.

So I was at a cross roads. I already had the six courses required for my sixth semester. I already took a professional option course. I didn’t need to take another open source class, I could just move on and do open source on the side.

And then I showed up to the first class.

Half an hour in, I was registering myself in the course. What can I say other than humphd made a very convincing introduction to the course?

My goal for the semester would be to work on the front end of Telescope and use my creative skills so that the UI looks as best as it can.

Fast in every way that matters

“‘How did he happen to do that?’ I asked after a minute.
‘He just saw the opportunity.'”

F. Scott Fitzgerald

When I decided I wanted to work with the front end, I knew I wanted to use GatsbyJS. I had only done translation for it, but I wanted to use it and Telescope was the right opportunity for it.

GatsbyJS is a React-based framework that generates static sites. It utilizes popular web technologies such as Webpack, GraphQL, ES6+ JAvaScript, and CSS. This allows Gatsby to not have too much of a learning curve as it is made with technology that programmers are familiar with.

Gatsby also has a big community and plugins that allow us to use already made solutions rather than create our own for scratch.

Furthermore, as an increasingly popular framework I thought it would be good to implement it and use it. It felt like valuable experience and worthwhile for the project.

How I Learned to Stop Worrying and Created a Gatsby Site

“To learn something new, you need to try new things and not be afraid to be wrong.”

Roy T. Bennett

For the second week, I decided to learn the basics about making a Gatsby site in order to convince the rest of the team that Gatsby would be a good fit. The process what’s pretty easy, and while css is never entirely painless, I felt pretty good after making some quick sites. I go in to more detail in my blog post about creating Gatsby sites, which can be read by following the link in the title.

An Unexpected Journey

“The great enemy of communication, we find, is the illusion of it.”

William H. Whyte

The day was Wednesday and I was ready to add Gatsby to Telescope. A simple “Hello World” starter from the Gatsby docs would be more than enough to get the team started with the front-end. I figured a bunch of issues could be filled out after the blank slate was merged and I could get the ball rolling.

Having gone through all the issues during a triage meeting, I saw that there were a few contributors eager to help with the font-end and the UI. Issues #511, #512, and #513 made me optimistic about being able to have a good interface by the time release 0.5 came about. After all, the strength of open source was the numbers. The many can do more than the one.

It…didn’t quite worked out that way.

When I looked at the Telescope repo that Wednesday morning, I noticed someone else beat me to it. A pull request that read “Initial frontend work for GatsbyJS app.”

It was then when I first realized I needed to communicate more about what I was doing. I had realized some time before Wednesday that I needed to keep up with the conversations going on Telescope – as I had missed important discussions about how we wanted Telescope to look.

But just reading and giving your opinion is not enough. Communicating what you are doing and what you are going to do are also important.

This was only the beginning.

The initial template from the pull request looked like so:

While not the “Hello World” starter I had in mind, It looked like a good base to start with. Besides, I never told anyone how I planned to start the front-end. As far as I’m aware, there are no telepaths working on Telescope.

However, there were some changes requested and it did not pass the tests. This meant we could not merge the pr, which was disappointing as I wanted to work on the front-end ASAP. There was a week left for release 0.5 after all.

I regularly checked the pr hoping to see some changes, ready to review and merge, but nothing really happened until two days later.

It was Friday.

Seeing another comment made me happy. The too red x beside the title of the pr? Not so much.

While the pr had been updated, there was no response to any of the changes requested in regard to the failed tests. This was yet another failure in communication, but also one due to our lack of knowledge about ESlint. I’ll return to this point later, though.

The updates have been changes to UI, so now the interface looks like this:

telescope1

The weekend passed without any comment. And I admit, it is frustrating to look back and see how much time had passed, and how little I asked for updates on the UI. Because, not only was this putting us behind for release 0.5, what was I going to do for my release 0.5?

I couldn’t work on code that had yet to be merged. At least, when it came to the UI.

It wasn’t until Monday that I talked about the status of the pr and laid out a plan of action. It needed to be a priority – at 5 days, it was the oldest pr of the semester and it was halting the development of the front-end. Additionally, going forward, small issues would be issued to better utilize our contributors, and we’d use Adobe XD for prototyping and getting feedback on the designs.

When I checked the pull request later on Monday, more changes had been requested and the status remained red. Luckily, the changes were more nits that could be worked on later on.

On the Tuesday, @humphd filed an issue to “Add static route to serve new GatsbyJS front-end.” I signed on, and started working on it that afternoon. I was not sure what I needed to do, and the lack of a Gatsby site meant that I couldn’t quite test out what I was learning.

So I decided to make a test site to work on my issue, I had waited long enough. It was then when I finally realized why the other pr kept failing.

ESlint.

Telescope is the only project I’ve worked on that uses ESlint. All my test sites have been made without it, and I had never looked into what ESlint did or how it worked. What I’m saying is that it had never been and issue.

Until now.

So I filled and issue. I waited about 10 minutes, and then assigned the issue to myself. Might as well do something outside of my comfort zone, right?

You can read more about how I dealt with that in this link, and you can see my pull request in this link.

So after all that time, ESlint tests failed the pr because we hadn’t added a React plugin.

Finally, today, Friday January 24th, the pr was merged. Telescope has a new front-end!

2020/01/25 02:03:14 EST

The past three weeks flew by.

A blink, an another day passes by. It certainly doesn’t help having a computer that loves taking its time to run anything. Neither does scrolling through reddit, if I’m honest.

My contributions weren’t quite what I expected. Though I admit, I still learned quite a bit, though not all was technical knowledge. If anything, I now know how much time can be wasted through a lack of communication, or by not being on the same page.

We all have different priorities and different projects we want to work on, so not only is it necessary to speak up, it is necessary to make sure you are understood.

Also. Following up on people is better than just silently anguishing.

On the bright side, I feel fairly comfortable working with Gatsby and I’m not afraid of touching the ESlint file anymore.

However, there is a lot for me to work on for the next release.

It’s fine :’)

ESlint: A Brief Guide on eslint-react-plugin

A project I’m working on has ESlint installed. I never really looked at what it did, and only had a vague idea of what it did. It wasn’t until we decided to add React to our project that I was sort of forced to look into ESlint more than I had previously.

If I was being honest, I feared it a bit. I knew the guy who had initially added ESlint to the project, and he didn’t looked too happy when he worked on it. I also remember that it broke a couple of pull requests after it was added. So I was wary.

BUT after having done this, I will say my fears were way overblown. It broke nothing and it took me longer to run the tests than it did to make my fix.

What is ESlint?

“ESLint is an open source JavaScript linting utility originally created by Nicholas C. Zakas in June 2013. Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines.”

Eslint Org (https://eslint.org/docs/about/)

ESlint is supposed to allow the developers to create a style to enforce on their JavaScript code. It is useful because the loosely-typed nature of JavaScript allows for errors that arise from humans and computers not being on the same page.

While you might think you coded one thing, the compiler doesn’t always interpret it that way.

Additionally, it is helpful in open source, since it can get kind of chaotic with all the programmers with their own preferred coding styles.

What is Eslint-Plugin-React?

A philosophy of ESlint, is that it allows for whoever sets it up, to add their desired rules and settings. Plugins are a way to do it.

So Eslint-Plugin-React is a plugin that allows React specific rules, such as recognizing .jsx files. Otherwise, you get errors when you run ESlint tests.

For example, in the project I had been working on, “Error: Unexpected token < found” kept popping up whenever I wanted to write a class. Not a fun message to find when a deadline is approaching. For a moment I thought I just didn’t know how to write a React class.

Installing the Plugin

I will assume you already have ESlint intsalled.

If you have ESlint installed locally, as in only for one project, run the following command:

npm install eslint-plugin-react --save-dev

However, if you have ESlint installed globally, the plugin must be too.

npm install -g eslint-plugin-react --save-dev

Now, you need to make some changes to the .eslintrc file. Remember that your project might have different needs. To better see what your project needs, go to plugin repo. In telescope, we needed to make the following changes:

This section did not previously exist
This section was added to the rules section