
Vercel released [Cron Jobs](https://vercel.com/blog/cron-jobs) recently! That is
pretty cool. It's a feature a lot of people longed for because something like
this was not available yet when using serverless environment like Vercel.

Now you can automate repetetive tasks without having a backend. To get started
with Cron Jobs in Vercel you have to create a `vercel.json` file. Here are some
example Cron Jobs:

```json
{
  "crons": [
    {
      "path": "/api/backup",
      "schedule": "0 0 * * *"
    },
    {
      "path": "/api/weekly-mail",
      "schedule": "0 0 * * 1"
    }
  ]
}
```

Cron Jobs use a specific syntax to determine the time when the job should be
executed. The schedule string consists of five fields separated by spaces. They
stand for minute, hour, day, month and day of the week.

So the first job in the example above will be executed **every day at
midnight**. While the second job will be executed **every Monday at midnight**.

With the Hobby plan you get two Cron Jobs for free which each can be triggered
once per day, while the Pro plan offers 40 Cron Jobs in total with unlimited
usage per day.

Here's the full documentation of Cron Jobs in Vercel:
[Cron Jobs](https://vercel.com/docs/cron-jobs)


Today I learned that Vercel introduced Cron Jobs recently. So now you can automate repetetive tasks in a serverless Environment like on Vercel.

Vercel Cron Jobs


If you've worked with React you've possibly done something like this to fetch
data from an API:

```js
const [data, setData] = useState(null)

useEffect(() => {
  fetch('https://pokeapi.co/api/v2/pokemon')
    .then((res) => res.json())
    .then((data) => setData(data))
}, [])
```

With the release of React 18 a lot of people were wondering if this is still a
good practice. The confusion stems from the fact that React 18 renders
everything twice in strict mode in development.

In this react thread on the react subreddit, Dan Abramov, a member of the React
core team at meta, shares a lot of valuable information on this topic:

[What is the recommended way to load data for components in React 18?](https://www.reddit.com/r/reactjs/comments/vi6q6f/what_is_the_recommended_way_to_load_data_for/)

Here are the **key takeaways** from his post:

- Running effects twice shouldn't break your code. You should always ignore
  stale responses. If it does break your code, you have race conditions to fix.
  One way to do this, is to implement a cleanup function. This article offers a
  great explanation on how to do this:
  [react docs: fetching data](https://beta.reactjs.org/learn/synchronizing-with-effects#fetching-data)

* If you can, switch to server-side data fetching. Next.js and Remix both offer
  built-in solutions to deal with that, which are better suited than client-side
  data fetching in effects. If a server-side framework isn't an option, consider
  using a client-side cache like [React Query](https://tanstack.com/query/v4/)
  to fetch data.

**A final note:** these changes have nothing to do with the release of React 18.
In fact, these issues have existing much longer. The react team just started
documenting them now. The main issue here is, that we may have all used effects
like useEffect wrong the whole time.

I've already wrote about that topic on other posts like my blog post
[the mistakes I made using React](/blog/the-mistakes-i-made-using-react/) and my
Today-I-learned post:
[missusing useEffect](/today-i-learned/missusing-use-effect/).

Now's a great time to refactor and apply the changes mentioned above.


Today I learned, about the best way to handle data fetching in React 18.

Data fetching in React 18


As I was recently part of a team developing a RESTful API, I stumbled a lot
about the **differentiation** between POST and PUT requests. I really tried to
find clear definitions for both of these CRUD Operations.

After searching the whole Internet, my **conclusion** was:

> _"Both PUT and POST can be used for creating."_

and

> _"POST should be used to create a resource, and PUT should be used to modify
> one"_

and

> _"PUT should be used to create a resource, and POST should be used to modify
> one"_

Great.

After searching some more I found this statement: "Better is to choose between
PUT and POST based on idempotence of the action.".

Idempotence? What's that now?

**Idempotence** or an **idempotent operation** means it has no additional effect
if it is called more than once whith the same input parameters. PUT is such an
idempotent operation.

Here is an example:

If a user sends a PUT request twice because the network failed at first and
nevertheless both request manage to make it to the server, that's not a problem.

If the same happens with a POST request, that can cause some bad side effects,
like updating different parts of an object.

So updating something twice is bad and you're doing it with POST? Use PUT for
that!

Other than that I'm still not 100% sure if I've understood the distinction of
PUT and POST, but the idempotent example clears a few things up.

I keep coming back to this
[stackoverflow thread](https://stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http)
where I think there is a lot of knowledge in there.


POST vs. PUT


Today I learned about headless wordpress. Wordpress now offers a REST API which
makes it possible to decouple the frontend completely from the wordpress
backend.

This is pretty cool, because I'm faster and more comfortable with JavaScript
when developing the frontend compared to the wordpress way where you mix you're
HTML with PHP.

For example: This makes it possible for me to use GatsbyJS for the frontend and
consume the content from wordpress through the API. Gatsby offers a plugin to do
all the heavy lifting for me and enables the bridge between wordpress and
Gatsby:
[gatsby-source-wordpress](https://www.gatsbyjs.org/packages/gatsby-source-wordpress/)

Of course this brings some pros and cons with it. I researched a bit and
collected a few articles which go into detail about using wordpress as a
headless CMS.

From the gatsby documentation:
[What is Headless WordPress?](https://www.gatsbyjs.com/docs/glossary/headless-wordpress/)

From Chris Coyier on css-tricks.com:
[Just How Niche is Headless WordPress?](https://css-tricks.com/just-how-niche-is-headless-wordpress/)


Headless Wordpress


Today I learned, that passing **unencoded text** into the body of a POST request
is a bad idea. It could result in security issues and therefore always should be
encoded.

One approach to resolve this is using `URLSearchParams`. You can learn more
about the API on mdn:
[https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams)

Jake Archibald wrote a blog post about this topic, where he explains it in more
depth:
[https://jakearchibald.com/2021/encoding-data-for-post-requests](https://jakearchibald.com/2021/encoding-data-for-post-requests)


Today I learned

Vercel Cron Jobs

Data fetching in React 18

POST vs. PUT

Headless Wordpress

Encoding POST request body