Use ts-rest fetch client on front-end to interact with API

DigitalCommons / mykomap-monolith

A web application for mapping initiatives in the Solidarity Economy

0 stars 0 forks source link

Use ts-rest fetch client on front-end to interact with API #10

Closed rogup closed 2 months ago

rogup commented 2 months ago

What? Why?

Related to issue #4

Since we have added a ts-rest contract to define the api in the common lib, we are using a ts-rest client on the front-end to consume the contract and benefit from the type safety.

There are also some other slightly related changes in this PR which I ended up doing at the same time, but they are clearly separated in the commit history.

Checklist

[x] Updated README
n/a Added UTs
- this code itself doesn't really need UTs, but we can make use of ts-rest Fake APIs later when we want to add automated regression tests for the front-end (e.g. with Playwright or Backstop JS) https://ts-rest.com/docs/guides/fake-apis
n/a Checked that all automated tests pass

Deployment notes

rogup commented 2 months ago

@wu-lee Please can you give these changes a quick review? (it's easier to have a look at each commit in order)

wu-lee commented 2 months ago

Seem to make sense, no glaring questions. I'm not going to sign off every commit as that seems excessive, just offer a general :+1:

Some prettification mixed in with changes mean I need to mentally skip those bits.

Some changes seem unrelated to the branch topic, like the GH pages removal?

Aside: I find that package-log.json to be a source of major meaningless churn and so I tend to put changes to this file in their own commits, at the end of a branch after everything has settled down. Not a big deal, but it does help when rebasing around other people's commits when they also change that file - as you tend to have to stop and resolve the conflicts every time it gets touched, typically by deleting it and running npm install again.

rogup commented 2 months ago

@wu-lee Thanks.

I can't see any prettification happening in these commits.

Yes, there are a couple of commits which are a bit unrelated, which I mentioned in the description of this PR. I should probably have stashed them for later, but I think it's fine since I won't be doing a squash merge anyway, and they're in separate commits.

Good point about the package-lock.json, I'll do that in one commit in the future to help with rebasing.