feat: add network request example with layered architecture

[bogy0]

This PR adds a simple end-to-end example of how to fetch data. The goal is to give developers a real example how to do this.
(FYI: This PR is a rework of #87. The original branch was created about three months ago and diverged significantly from main, so I recreated the feature on a fresh branch based on the latest main.)

This PR also gives example how to access params/queries in client component

What’s included

PostComponent example

Added a small React component that loads a "blog post" + its "comments". It shows:

• how to call the API,
• and how to keep the UI clean by not mixing fetch logic into the component.

Clear separation between layers

• UI layer: React component that just renders stuff
  src/pages/welcome/post/PostComponent.jsx
• API layer: tiny client-side wrappers around the backend routes
  src/api/message.js
• Service layer: server-side handlers that talk to an external API (mocked here)
  src/service/postHandlers.js, src/service/externalHandlers.js

This should make the overall flow easier to follow and copy/paste for future features, also testing can be easier.

New endpoints

• GET /api/post/:id
• GET /api/comments?postId=:id
• GET /api/external/post/:id
• GET /api/external/comments?postId=:id

These external endpoints are mocked
— they’re only here to demonstrate how the service layer would normally proxy to some real third-party service.

Dashboard extended with handling url params/queries

• /dashboard/1234?q=xxx&name=Anne

This is how this new section looks in the welcome page:

Modified dashboard page, to demonstrate how to handle params/queries client-side:

[rodet]

Looks good overall! Please review my comments. Later on we should add more test cases but this could be a separate PR.

[lee-chase]

@bogy0 made a small number of changes to fix preview:prod.

Turns out that at run time Express insists on the whole object being selected.

I was also a bit confused about the posts/comments.

The id and postId always seemed to be one.
In addition it would be nice to prevent invalid IDs. Suggest 400 for invalid ID, 404 for out of range/not found.

[bogy0]

@lee-chase Thanks for your changes to make the preview:prod command work again.

For your other comments:

I was also a bit confused about the posts/comment
The id and postId always seemed to be one.

The Welcome page's <PostComponent> file was written in a way that it loads the first post:

carbon-react-router-starter/src/pages/welcome/post/PostComponent.jsx

Lines 9 to 16 in e037b45

	const loadPost = async () => {
	try {
	const post = await getPost(1);
	setPost(post);
	} catch {
	setPost('Failed to load message');
	}
	};

Again this is just an example usage, if you have better idea how you want to demonstrate this in the Welcome page, let me know, but based on your comment im more like confused, then confident whats the goal. If you want to i can write a random loadPost logic so we load a random post from our service. Thats what you meant?

---

The id and postId always seemed to be one. In addition it would be nice to prevent invalid IDs. Suggest 400 for invalid ID, 404 for out of range/not found.

The src/service/externalHandlers.js file already handles the case when invalid post id is passed, and it gives back 400 status code with message Post not found.

carbon-react-router-starter/src/service/externalHandlers.js

Lines 94 to 96 in e037b45

	if (!post) {
	return res.status(404).json({ message: 'Post not found' });
	}

[lee-chase]

Hi @bogy0, perhaps my understanding of what we are demonstrating is incorrect. I expected postId and id to match some back end identifier and thought by changing the params I might see that.

As for the 404: "Post not found" that is correct, but if the wrong ID format is supplied it may be more appropriate to return 400: Bad request.

Happy for you to reject both these thoughts and approve.

[bogy0]

As for the 404: "Post not found" that is correct, but if the wrong ID format is supplied it may be more appropriate to return 400: Bad request.

Happy for you to reject both these thoughts and approve.

The case if post id format is invalid is also covered, and responds with 400 http status, message:

[bogy0]

Hi @bogy0, perhaps my understanding of what we are demonstrating is incorrect. I expected postId and id to match some back end identifier and thought by changing the params I might see

@lee-chase now i understand, sorry for my confusion, so what i did to address this in my latest commit (9a3fb40) is that i added a postId property to the <PostComponent /> and also added JSDoc, so at the Welcome page now its controllable which post we want to load.

Issue being raised to deal with test coverage.