DEV Community: Antoine Mincy

Hook Dev.to blogs to your react app

Antoine Mincy — Wed, 13 Oct 2021 02:23:54 +0000

So, I love the Dev.to community and more so I love how easy it is to create a blog. So, I was looking for a way to have my blogs that I publish on here go straight to my personal site. Thankfully, this was pretty easy due to dev's api and a couple react hooks. Here is how I implemented mine on my personal site.

Direct to a specific blog article
List your blog articles on a page
Dynamically go to a blog article from a list

In a rush? Here is the Github Repo

For the sake of time I am going to make a few assumptions here:

You are familiar with React and React Hooks
You have a basic understanding of an API
You have at least one published article on Dev.to

1. Direct to a specific blog article

Let's start with creating a basic react app: npx create-react-app dev-blog

Once the app is done installing let's do our usual boilerplate clean up of the App.js file. Here is mine:

function App() {

    return (
        <div>
            Dev Blog
        </div>
    );
}

export  default App;

Now let's take a look at the api docs here. While their api is still in beta, as you can see there are several ways you can retrieve data from the site. As you explore different paths and responses you may come across a few that are not correct or not returning but I have yet to come across one and overall am pretty pleased with their work.

The path I recommend is under articles and named the A published article by path GET call. Let's add a constant named blogPath to our code and we want to set that const to https://dev.to/api/articles/{Your UserName}/{Your Article ID} Simply navigate to a blog post you want show to get that Article ID. Here is mine.

function App() {
const blogPath = 'https://dev.to/api/articles/simplymincy/test-post-2-2j8a`';
    return (
        <div>
            Dev Blog
        </div>
    );
}

export  default App;

The next thing we want to do is make a call with that const to get the response body. To do this we can use useState and useEffect and a package commonly used with react called axios, which will be used to make our http requests. Let's go ahead and install that package npm i axios.

After that installs let's use the useState hook and set it to be our article Body response.

import React, { useEffect, useState } from  "react";
import axios from  "axios";

function App() {
const blogPath = 'https://dev.to/api/articles/simplymincy/test-post-2-2j8a`';
const [articleBody, setArticleBody] = useState();

    return (
        <div>
            Dev Blog
        </div>
    );
}

export  default App;

To actually get that response we will need to now use useEffect and axios to make that call using the blogPath we created. It should look something like I have below with us checking for the response.data and setting that to our setArticleBody. Be sure to set a dependency here in your useEffect or this call will continuously run in the background. We only want this to update if there is a page load so we can set it dependent to the blogPath.

Axios makes it really easy to make requests. Feel free to check out their docs

import React, { useEffect, useState } from  "react";
import axios from  "axios";

function App() {
const blogPath = 'https://dev.to/api/articles/simplymincy/test-post-2-2j8a`';

const [articleBody, setArticleBody] = useState();

    useEffect(() => {
        axios.get(blogPath).then((response) => {
            setArticleBody(response.data);
        });
    }, [blogPath]);

    return (
        <div>
            Dev Blog
        </div>
    );
}

export  default App;

Now at this point you would think we could replace the contents in the return with one of the properties we are getting in our response. I mean for sure "body_html" property should work right? Just use that and place that in the return. I am sure you know the problem with trying that but if you don't it is because that return is not real HTML. It is jsx. So, it will not do any formatting. So, instead let's go with the "body_markdown" property instead and to get the markdown formatting to show up correctly on our page we are going to use another package react-markdown. This package converts your markdown code into code jsx can understand and displays it properly. So, let's install that package and make those updates shall we:

function App() {
const blogPath = 'https://dev.to/api/articles/simplymincy/test-post-2-2j8a`';

const [articleBody, setArticleBody] = useState();

    useEffect(() => {
        axios.get(blogPath).then((response) => {
            setArticleBody(response.data);
        });
    }, [blogPath]);

    if (!articleBody) return  null;

    const markdown = articleBody.body_markdown;

    return (
        <div>
            <ReactMarkdown>{markdown}</ReactMarkdown>
        </div>
    );
}

export  default App;

I've also added a simple check on the body response to see if it exists and to return null if it doesn't. That way our app will not crash if that path no longer exists.

At this point you should be able to see the page loaded with your article. This is pretty basic but we can do some more dynamic things with this api.

2. List a collection of articles on a page

So, first thing we want to do here is make a new component. Let's call it Article.js because this is where we will return... well our articles.

 const Article = () => {
        return ();
 };

 export  default Article;

And since we did all that work already in our App.js file. Let's just move that over to this Article.js file.

import React, { useEffect, useState } from  "react";
import axios from  "axios";
import ReactMarkdown from  "react-markdown";

const Article = () => {

const blogPath = `https://dev.to/api/articles/simplymincy/test-post-2-2j8a`;
const [articleBody, setArticleBody] = useState();

    useEffect(() => {
        axios.get(blogPath).then((response) => {
            setArticleBody(response.data);
        });  
    }, [blogPath]);

    if (!articleBody) return  null;

const markdown = articleBody.body_markdown;

    return (  
        <div> Dev Blog
            <ReactMarkdown>{markdown}</ReactMarkdown>
        </div>
    );
};

export  default Article;

Our App.js should be empty now and look like this:

import React from  "react";

function App() {

return (
<div>
Empty App
</div>

);

}

export  default App;

Before we do anything else to that file let's create our collection component Collection.js with some of the same imports as before:

import React, { useEffect, useState } from  "react";
import axios from  "axios";

const Collection = () => {

return ();    
};
export  default Collection;

And we want to retrieve the data similar to how we did with the Article component but we want to use this url https://dev.to/api/articles?username={Your UserName} to get the collection of articles instead.

import React, { useEffect, useState } from  "react";
import axios from  "axios";

const Collection = () => {
    const collectionPath = `https://dev.to/api/articles?username=simplymincy`;
    const [articleCollection, setArticleCollection] = useState();

    useEffect(() => {
        axios.get(collectionPath).then((response) => {
            setArticleCollection(response.data);
        });
    }, [collectionPath]);

    if (!articleCollection) return  null;

    return  <div>Dev Collection</div>;
};

export  default Collection;

Since we will be getting an array of data we will use the map() method to display every element. It should look something like I have below where we are taking that articleCollection and spitting out every article (You can name that whatever you like) based on its id.

const list = articleCollection.map((article) => (

    <div  key={article.id}>
        Data we want to display here
    </div>
));
    return (
        <div>Dev Collection
            {list}
        </div>
    );

I also want to display an image and the title of the article so I will add a couple more but feel free to add whatever you like here based off the api.

import React, { useEffect, useState } from  "react";
import axios from  "axios";

const Collection = () => {
    const collectionPath = `https://dev.to/api/articles?username=simplymincy`;
    const [articleCollection, setArticleCollection] = useState();

        useEffect(() => {
            axios.get(collectionPath).then((response) => {
                setArticleCollection(response.data);
            });
        }, [collectionPath]);

    if (!articleCollection) return  null;
    const list = articleCollection.map((article) => (

        <div  key={article.id}>
            <div>
                <div>
                    <img  src={article.social_image}  alt="Article Images"  />
                </div>
                    <div>
                        <h4>{article.title}</h4>
                    </div>
                </div>
            </div>
        ));

    return (

        <div>
            Dev Collection
            {list}
        </div>
    );
};

export  default Collection;

Let's now import the Collection component in our App.js file

import React from  "react";
import Collection from  "./Collection";

function App() {

    return (
        <React.Fragment>
            <Collection/>
        </React.Fragment>
    );
}

export  default App;

We should now see a collection of our published articles on our page. Now the last thing we want to do (besides adding some css to have it more appeasing on our eyes) is have each article clickable and navigate to that particular article onClick. Let's do that now.

3. Navigate to a blog article from a list

For this we are going to use another common package that is used with React and that is react-router-dom. So, let's install that and before we get the Collection component ready to have a clickable element we need to go to our App.js file and make a few changes. Right now our app is a single page app. Being that we will at the very least now have 2 pages we can now navigate, we need to set up some routes. This is a decent enough change so for this one I am going to show the fully updated App.js file and then explain.

import React from "react";
import { BrowserRouter, Switch, Route } from "react-router-dom";
import Article from "./Article";
import Collection from "./Collection";

function App() {
  return (
    <React.Fragment>
      <BrowserRouter basename={"/"}>
        <Switch>
          <Route
            exact
            path={`${process.env.PUBLIC_URL}/`}
            component={Collection}
          />
          <Route
            exact
            path={`${process.env.PUBLIC_URL}/Article/simplymincy/:path`}
            component={Article}
          />
        </Switch>
      </BrowserRouter>
    </React.Fragment>
  );
}

export default App;

I am now using the react-router-dom package in our most top level component because I want to set up the different routes I spoke of before. Hence why we are using the BrowserRouter, Switch, and Route methods. The BrowserRouter tag is used to push, replace, and pop the various return states we will now have in our app. Inside of that we set a Switch tag which works very similiar to a switch statement meaning that it returns the first child it has that matches a location and as you can see we have 2 Route tags. There are a lot of properties you can set for these and I highly recommend looking over the docs here, but for my example I am checking for an exact match on the path property and I am setting the components to the 2 components we created earlier. Looking closer you will see that I have the Collection component set as my base url and the route with the Article component with a more unique path. The /Article/simplymincy/ was simply what I chose here but you can have your path be anything as long as it is unique.

Last thing, I want to point out here is the :path piece you see in that url. We use this here so that when we do eventually click on a link in our Collection component we will pass it some parameters. We do that by importing react-router-dom to our component and using the Link method. Think of this as an <a> tag. Here is the updated file now:

    import React, { useEffect, useState } from  "react";
    import axios from  "axios";
    import { Link } from  "react-router-dom";

    const Collection = () => {
        const collectionPath = `https://dev.to/api/articles?username=simplymincy`;

        const [articleCollection, setArticleCollection] = useState();

        useEffect(() => {

            axios.get(collectionPath).then((response) => {
                setArticleCollection(response.data);
            });
        }, [collectionPath]);

        if (!articleCollection) return  null;

        const list = articleCollection.map((article) => (

            <div  key={article.id}>
                <div>
                    <div>
                        <img  src={article.social_image}  alt="Article Images"  />
                    </div>
                    <div>
                        <h4>{article.title}</h4>
                    </div>
                </div>
                <div>
                    <Link  to={`/Article/simplymincy/${article.slug}`}>Read</Link>
                </div>
            </div>
        ));

    return (

        <div>

            Dev Collection
                {list}
        </div>
        );
    };

    export  default Collection;

As you will notice in the Link tag we are using the same url that we set in the Article route in the App.js file. That is key, because remember we are using exact match here. If they do not match it will not return our Article component. Which leads us to our last step. Remember when we set the :path in our Article route well we did that so we can set some value and pass it through our components freely. In this case we are going to use a value we get from our api call, which is slug. This by the definition of the dev.to api is used to uniquely identify the articles users create. This is not only perfect to have our urls be unique but also will be able to get passed through so our Article component can make a direct call on that path to gets its blog content. This update is rather small. We just want to import { useParams } from "react-router-dom"; and then replace our blogPath const with this:

    const params = useParams();
    const blogPath = `https://dev.to/api/articles/simplymincy/${params.path}`;

What we are doing here is passing in the parameters from the link we clicked on in the Collection component and we will set that slug to be the end of our blogPath. That way no matter what article we click on, it will know which one to retrieve its content for and display.

AND THATS IT!

At this point you should have all of your articles in a collection displaying and be able to click and display each article dynamically. With the API you can do a lot more such as GET and POST comments, likes, and other useful stats pertaining to your blog. I did not add any styling in here either. I leave that up to you. Here is an example of how I implemented mine.

From my personal site

Refactr.Tech (2021)

Antoine Mincy — Tue, 31 Aug 2021 20:13:03 +0000

It is only fitting that my first blog is about this conference. Even though I have been in the tech field for close to 10 years now, Refactr was the first conference I ever attended in 2019. It was also the first one they ever held. The focus on inclusion and diversity was a major factor, due to me struggling with finding my voice in the tech industry. That was not the only plus. There were several different speakers and paths like many conferences I imagine but seeing myself in so many people and hearing their wins and struggles made me feel seen. I learned so much about the pain points in our industry and was motivated to do my part to help not only my organization do better in these areas but our industry as a whole. Our QA department benefited greatly as well. We took the cypress.io workshop and got a solid foundation that we are still building on today. Moving our testing efforts from 100% manual testing to 90% automation and 10% discovery testing.

The first question you may be asking is " was Refactr.tech conference 2021 just as great?" Well, no. BUT that is not the fault of the organizers. Considering we are still in a pandemic, this year was virtual and therefore a lot of the value I got from in person networking was gone. Having said that, I still enjoyed the conference and have thoughts on a few of the topics.

Day 1

Growing in our Careers

Speaker Lara Hogan

The focus of this talk was all the things you should look for in a mentor or if you are the one doing the mentoring, a mentee. It was gathered from an AWS article and for the most part there was nothing new here.

Make sure the relationship is beneficial to both parties
look for a mentor with a good work life balance
do not be afraid to walk away if it is not beneficial

you know the usual stuff you hear when it comes to mentor advice. The one thing that did catch my attention however, was the idea of Sponsorships.

Now up until this point I always thought of sponsorships as a synonym for mentor, but Lara says that is not the case. A sponsor is someone who is not just telling a person what they should be doing but actively advocating for that person. This means if that mentor of yours is at your job, they are looking for opportunities for you to grow and they are advertising your name as a person people should consider to do a job. Lara emphasized the power of sponsorship over just mentoring. Especially in marginalized groups. She stated that marginalized people are over-mentored and UNDER sponsored. For someone like me who struggled finding a place in the tech space early in my career, I can totally relate to that statement.

Where to start with AWS as a Developer

Speaker Sam Julien @samjulien

This was the second topic that caught my attention during day 1 of the conference. Our company relies heavily on AWS and besides the simple tasks I do day to day when connecting to our server, I am total noob. So, when Sam started to talk about what it takes to learn AWS I was all ears.

Cloud is a way to virtualize your network infrastructure. When thinking about vertical or horizontal scaling of your business, the cloud solution helps with the capital vs. operating expenses problem, by providing a service that handles that for a fraction of the costs.

After going over the basics, Sam went over some key services developers should get familiar with such as:

EC2
Lamda
S3

He also mentioned some pitfalls to watch out for while learning AWS:

Pay attention to your billing. You are billed each month so if you are not on top of things you may be surprised by that end of the month bill. To combat this, clean up your resources after working or setting them up. Do not just leave them up while you are simply learning the tools.
Use labs and the free tier
Set up billing alarms. This is good not just for learning but in general. Let's say you have an app/site out in production and you know your average traffic rate per month and adjust your billing to handle that expense. Well, all it takes is one viral moment or a confusion in url to make that site much more popular than you intended. Billing alarms are a good way to stay on top of those moments.
Identify and Access Management. Use the principle of least privilege. In other words, only give access to the people that need it and make sure their levels of access is proportionate to their needs.

Lastly, he went over the certification paths depending on the job you may want to take in the future. He also mentioned you do not need these certifications to apply for jobs, but are great if you are looking for a deep understanding of cloud services and tooling in a given area such as:

Cloud Practitioner exam
Cloud Practitioner - Supervising the architecting and deployment of applications within AWS platforms.
Associate Exams
Solutions arch - responsible for evaluating an organization's business needs and determining how IT can support those needs leveraging software,
SysOps Admin - responsible for providing the necessary knowledge related to the working of cloud computing, IT and business applications to improve service delivery.
Developer - create applications that are served on the cloud
1. Profesional Exams
2. Solutions arch - Same as it was with the associate exam but you should have a deeper understanding at this point
3. DevOps Engineer - A DevOps engineer introduces processes, tools, and methodologies to balance needs throughout the software development life cycle, from coding and deployment, to maintenance and updates.

Day 2

Moving beyond Performative Racial Equity in Tech

a conversation with

Albrey Bristo-Brown & Nicole Sanchez

This was not the typical powerpoint presentation. This was more a conversation between the two presenters. If you have worked in a tech company in the past couple years, you might be familiar with this format. This is a pattern many diversity training companies take, as they want to not come off as preaching to a group and have the topic be more approachable.

The business is now in high demand according to Nicole, she has been doing this for decades and there was a big difference in 2020. She is doing many more talks than before and states part of that is because white America was not listening before but now they are. She then stated right after that it is because people of color are speaking up more and not afraid of any of the repercussions that might come from it. The engagement is actually there and we are no longer waiting on the sideline for action to happen. There seemed to be a sense of urgency after the George Floyd video. This is when the conversation got interesting. They then break down how much of that was genuine.

The stat they threw out was 3.8 billion went towards helping black equity over that time but only 7% went towards education. Often companies made a one time commitment by donating money but this was more of a thing companies did to not be singled out for not doing anything. Those donations were often hollow without any follow up actions to do their part in battling racial inequalities. This is where the term Performative Racial Equity comes to play. I kind of wish I had this term in my vocabulary last year, because I remember telling my team that very thing when they were all trying to figure out what to do to make a statement that they too supported BLM after the George Floyd video. You see I am 1 of 3 black people in the company, and I believe the only black engineer. Yet, it was not until I saw the company trying really hard to make a statement in support of BLM when it was now convenient to do so, that I felt disgusted by my companies lack of proactive support before:

So what do we do. Albrey and Nicole talked about a few solutions.

Donate your time and not just your money.
Be sure to have open and honest dialogue with your employees.
When it comes to building a working environment where minorities and underrepresented people feel comfortable expressing themselves, do not have too many managers passed around. It is hard to establish a relationship of trust and more so a connection where that manager will take action, if they are constantly being moved around.
The last solution I found the most revealing. They stated that black women are usually the ones with the most hurdles they must overcome in not only the tech space, but any space in general. So, if a company can help solve the issues black women are having in the company then usually that helps with a lot of the other problems in the organizations with your underrepresented groups.

Day 3

Career Progression

Speaker Mekka Okereke

The following notes I got from my coworker Alex since I was out on day 3 but based on these notes I really wish I was there to hear the talk Mekka gave. As a person who has thrived in the scrum team dynamic his presentation clearly put some things in the forefront of my mind. He states in order to progress in your career you have to do these 4 things:

Skills. To perform at the next level

Opportunity. To demonstrate those skills

Perform. Put it all together

Be Recognized. Most important

Nothing mind blowing here but number 4 is the one that struck me. When working in scrum the idea is that no one person owns a ticket/task. It is the responsibility of the team to get tickets done. There are a lot of pros to that if you are doing proper pairing and swarming. For example, context of the ticket is shared amongst the team and you do not have to waste time getting others up to speed when it comes to code reviews and testing, others are able to fill in gaps of knowledge and cover technical blindspots you may or may not be aware of and generally the team is able to get the most important tickets done faster, but to Mekka's point, a con is that your actual contributions may get lost in all that shuffle.

He mentions that people need to see that you've done the work and that you are able to put it all together yourself. Just because you do good work, it does not mean you will automatically get recognized. Worse case scenario, if you do not advocate for yourself and your work, your work could be undervalued.

This made me think to one of the retro items our team started to include in our sprint. We added in our team working agreement that we can assign tickets to individuals in Jira but we should look at that person as the one driving that ticket. Meaning work should not be done in a silo. Look to pair when you can on the work. Until reading over the notes on Mekka's speech, I always thought of that as counterintuitive to scrum. Just the idea of putting your name on a task felt anti-scrum, but in a profession such as tech where it is sometimes easy to get overlooked, it might just be the best compromise to being recognized as an individual while still working in a team setting.