FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 2, column 247: Self reference doesn't match document location [help]

... ://www.peterbe.com/rss.xml" rel="self"/><language>en-us</language><lastB ...
                                             ^

line 2, column 0: Non-html tag: typeof [help]

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title> ...

Source: https://www.peterbe.com/rss.xml

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Peterbe.com</title><link>http://www.peterbe.com/rss.xml</link><description>Stuff in Peter's head</description><atom:link href="http://www.peterbe.com/rss.xml" rel="self"/><language>en-us</language><lastBuildDate>Mon, 18 Nov 2024 16:20:15 +0000</lastBuildDate><item><title>An ideal pattern to combine react-router with tanstack/react-query</title><link>http://www.peterbe.com/plog/ideal-pattern-react-router-with-tanstackreact-query</link><description>If you use loaders in React Router and have them start XHR requests on the same QueryClient you use in your components, you can start API requests before you render the React page. This makes the page feel faster to load because you can have the back-end data ready for your eyes to feast on sooner.</description><pubDate>Mon, 18 Nov 2024 16:20:15 +0000</pubDate><guid>http://www.peterbe.com/plog/ideal-pattern-react-router-with-tanstackreact-query</guid></item><item><title>brotli_static in Nginx</title><link>http://www.peterbe.com/plog/brotli_static-in-nginx</link><description>`apt install libnginx-mod-http-brotli-static`</description><pubDate>Fri, 08 Nov 2024 17:06:28 +0000</pubDate><guid>http://www.peterbe.com/plog/brotli_static-in-nginx</guid></item><item><title>Object.keys to return the known strings of an object in TypeScript</title><link>http://www.peterbe.com/plog/object.keys-known-strings-object-ts</link><description>Use `keyof typeof myObject` to get the keys as an "list of strings" that are the keys of an object.</description><pubDate>Fri, 25 Oct 2024 13:07:32 +0000</pubDate><guid>http://www.peterbe.com/plog/object.keys-known-strings-object-ts</guid></item><item><title>How I make my Vite dev server experience faster</title><link>http://www.peterbe.com/plog/vite-dev-server-experience-faster</link><description>Use `server.warmup.clientFiles` to make Vite get to work on transforms as soon as possible, rather than on-demand. See what's going on using `vite --debug transform`</description><pubDate>Tue, 22 Oct 2024 14:14:10 +0000</pubDate><guid>http://www.peterbe.com/plog/vite-dev-server-experience-faster</guid></item><item><title>How to extend a function in TypeScript without repeating the signature types</title><link>http://www.peterbe.com/plog/extend-function-typescript-same-signature-types</link><description>Use the `Parameters<typeof someFunction>` to be able to extend or control the signature of a function you don't want to spell out.</description><pubDate>Wed, 16 Oct 2024 12:28:18 +0000</pubDate><guid>http://www.peterbe.com/plog/extend-function-typescript-same-signature-types</guid></item><item><title>Trying out the new Bun "Compile to bytecode"</title><link>http://www.peterbe.com/plog/trying-bun-compile-to-bytecode</link><description>Bun 1.1.30 added a `--bytecode` option to `bun build` and it does appear to make the executable faster</description><pubDate>Tue, 15 Oct 2024 11:49:16 +0000</pubDate><guid>http://www.peterbe.com/plog/trying-bun-compile-to-bytecode</guid></item><item><title>The performance benefits of code-split an SPA</title><link>http://www.peterbe.com/plog/performance-benefits-of-code-split-an-spa</link><description>Code-splitting can be great for web performance, but it's most likely about the underlying heavy libraries rather than your own code *using* those libraries.</description><pubDate>Sat, 12 Oct 2024 21:01:30 +0000</pubDate><guid>http://www.peterbe.com/plog/performance-benefits-of-code-split-an-spa</guid></item><item><title>Rate my golf swing (October 2024)</title><link>http://www.peterbe.com/plog/rate-my-golf-swing-october-2024</link><description>Video of my swing as of October 2024.</description><pubDate>Fri, 11 Oct 2024 20:10:35 +0000</pubDate><guid>http://www.peterbe.com/plog/rate-my-golf-swing-october-2024</guid></item><item><title>The 3 queries I use with pg_stat_statements to analyze slow PostgreSQL queries</title><link>http://www.peterbe.com/plog/3-queries-with-pg_stat_statements</link><description>3 primary SQL statements you need when using pg_stat_statements</description><pubDate>Mon, 30 Sep 2024 17:03:10 +0000</pubDate><guid>http://www.peterbe.com/plog/3-queries-with-pg_stat_statements</guid></item><item><title>How to handle success and failure in @tanstack/react-query useQuery hook</title><link>http://www.peterbe.com/plog/how-to-handle-success-and-failure-usequery-hook</link><description>What <a href="https://tanstack.com/query/latest/docs/framework/react/overview"><code>@tanstack/react-query</code> is</a> is a fancy way of fetching data, on the client, in a React app.
Simplified primer by example; instead of...
<pre><code class="hljs">
function MyComponent() {
const [userInfo, setUserInfo] = useState(null)
useEffect(() =&gt; {
fetch(&#x27;/api/user/info&#x27;)
.then(response =&gt; response.json())
.then(data =&gt; {
setUserInfo(data)
})
}, [])
return &lt;div&gt;Username: {userInfo ? userInfo.user_name : &lt;em&gt;not yet known&lt;/em&gt;}&lt;/div&gt;
}
</code></pre>

you now do this:
<pre><code class="hljs">
import { useQuery } from &#x27;@tanstack/react-query&#x27;
function MyComponent() {
const {data} = useQuery({
queryKey: [&#x27;userinfo&#x27;],
queryFn: async () {
const response = await fetch(&#x27;/api/user/info&#x27;)
return response.json()
}
})
return &lt;div&gt;Username: {data ? data.user_name : &lt;em&gt;not yet known&lt;/em&gt;}&lt;/div&gt;
}
</code></pre>
<h2>That's a decent start, but...</h2>
Error handling is a thing. Several things can go wrong:
<ol>
<li>Complete network failure during the <code>fetch(...)</code> </li>
<li>Server being (temporarily) down </li>
<li>Not authorized </li>
<li>Backend URL not found </li>
<li>Backend URL found but wrong parameters</li>
</ol>
None of the code solutions above deal with these things. At least not all of them.
By default, <code>useQuery</code> will retry if any error thrown inside that <code>queryFn</code> call.
<blockquote>
Queries that fail are silently retried 3 times, with exponential backoff delay before capturing and displaying an error to the UI.
</blockquote>
From the <a href="https://tanstack.com/query/latest/docs/framework/react/guides/important-defaults">documentation about important defaults</a>
For example, if the server responds with a <code>403</code> the response body might not be of content-type JSON. So that <code>response.json()</code> might fail and throw and then <code>useQuery</code> will retry. You might be tempted to do this:
<pre><code class="hljs">
queryFn: async () {
const response = await fetch(&quot;/api/user/info&quot;)
+ if (!response.ok) {
+ throw new Error(`Fetching data failed with a ${response.status} from the server`)
+ }
return response.json()
}
</code></pre>
The problem with this is that <code>useQuery</code> still thinks it's an error and that it should retry. Sometimes it's the right thing to do, sometimes pointless.
<h2>About retries</h2>
The default implementation in @tanstack/react-query can be seen here: <a href="https://github.com/TanStack/query/blob/acb5d37f5c81753243978ff2f4b016c1009f3813/packages/query-core/src/retryer.ts#L164-L206"><code>packages/query-core/src/retryer.ts</code></a>
In a gross simplification, it works like this:
<pre><code class="hljs">
function run() {
const promise = config.fn()
Promise.resolve(promise)
.then(resolve)
.catch((error) =&gt; {
if (shouldRetry(config)) {
await sleep(config.sleepTime())
run()
} else {
reject(error)
}
})
</code></pre>
I'm not being accurate here but the point is that it's quite simple. The config has stuff like a count of how many times it's retried previously, dynamically whether it should retry, and how long it should sleep. 
The point is that it doesn't care what the nature of the error was. It doesn't test if the error was of type <code>Response</code> or if <code>error.message === "ECONNRESET"</code> or something like that.
So in a sense, it's a "dumping ground" for any error thrown. So if you look into the response, within your query function, and don't like the response, if you throw a new error, it will retry. And that might not be smart.
In simple terms; you should retry if retrying is likely to yield a different result. For example, if the server responded with a <code>503 Service Unavailable</code> it's quite possible that if you just try again, a little later, it'll work.
What is wrong is if you get something like a <code>400 Bad Request</code> response. Then, trying again won't work. 
Another thing that is wrong is if your own code throws an error within. For example, ...
<pre><code class="hljs">
queryFn: async () {
const response = await fetch(&#x27;/api/user/info&#x27;)
const userInfo = response.json()
await doSomethingComplexThatMightFail(userInfo)
return userInfo
}
</code></pre>
<h2>So, what's the harm?</h2>
Suppose that you have something basic like this:
<pre><code class="hljs">
queryFn: async () {
const response = await fetch(&quot;/api/user/info&quot;)
if (!response.ok) {
throw new Error(`Fetching data failed with a ${response.status} from the server`)
}
return response.json()
}
</code></pre>
and you use it like this:
<pre><code class="hljs">
function MyComponent() {
const {data, error} = useQuery(...)
if (error) {
return &lt;div&gt;An error happened. Reload the page mayhaps?&lt;/div&gt;
}
if (!data) {
return &lt;div&gt;Loading...&lt;/div&gt;
}
return &lt;AboutUser info={data.userInfo}/&gt;
}
</code></pre>
then, I guess if it's fine to not be particularly "refined" about the error itself. It failed, refreshing the page might just work.
<h2>If not an error, then what?</h2>
The pattern I prefer, is to, if there is a problem with the response, to return it keyed as an error. Let's use TypeScript this time:
<pre><code class="hljs">
// THIS IS THE NAIVE APPROACH
type ServerResponse = {
user: {
first_name: string
last_name: string
}
}
...
function MyComponent() {
const {data, error, isPending} = useQuery({
queryKey: [&#x27;userinfo&#x27;],
queryFn: async () {
const response = await fetch(&#x27;/api/user/info&#x27;)
if (!response.ok) {
throw new Error(`Bad response ${response.status}`)
}
const user = await response.json()
return user
}
})
return &lt;div&gt;Username: {userInfo ? userInfo.user_name : &lt;em&gt;not yet known&lt;/em&gt;}&lt;/div&gt;
}
</code></pre>
A better approach is to allow <code>queryFn</code> to return what it would 99% of the time, but also return an error, like this:
<pre><code class="hljs">
// THIS IS THE MORE REFINED APPROACH
type ServerResponse = {
user?: {
first_name: string
last_name: string
}
errorCode?: number
}
...
function MyComponent() {
const {data, error, isPending} = useQuery({
queryKey: [&#x27;userinfo&#x27;],
queryFn: async () {
const response = await fetch(&#x27;/api/user/info&#x27;)
if (response.status &gt;= 500) {
// This will trigger useQuery to retry
throw new Error(`Bad response ${response.status}`)
}
if (response.status &gt;= 400) {
return {errorCode: response.status}
}
const user = await response.json()
return {user}
}
})
if (errorCode) {
if (errorCode === 403) {
return &lt;p&gt;You&#x27;re not authorized. &lt;a href=&quot;/login&quot;&gt;Log in here&lt;/a&gt;&lt;/p&gt;
}
throw new Error(`Unexpected response from the API (${errorCode})`)
}
return &lt;div&gt;
Username: {userInfo ? userInfo.user_name : &lt;em&gt;not yet known&lt;/em&gt;}
&lt;/div&gt;
}
</code></pre>
It's just an example, but the point is; that you treat "problems" as valid results. That way you avoid throwing errors inside the query function, which will trigger nice retries. 
And in this example, it can potentially throw an error in the rendering phase, outside the hook, which means it needs your attention (and does not deserve a retry)
What's counter-intuitive about this is that your backend probably doesn't return the error optionally with the data. Your backend probably looks like this:
<pre><code class="hljs">
# Example, Python, backend JSON endpoint 
def user_info_view(request):
return JsonResponse({
&quot;first_name&quot;: request.user.first,
&quot;last_name&quot;: request.user.last
})
</code></pre>
So, if that's how the backend responds, it'd be tempting to model the data fetched to that exact shape, but as per my example, you re-wrap it under a new key.
<h2>Conclusion</h2>
The shape of the data ultimately coming from within a <code>useQuery</code> function doesn't have to map one-to-one to how the server sends it. The advantage is that what you get back into the rendering process of your component is that there's a chance of capturing other types of errors that aren't retriable.</description><pubDate>Mon, 16 Sep 2024 10:27:38 +0000</pubDate><guid>http://www.peterbe.com/plog/how-to-handle-success-and-failure-usequery-hook</guid></item></channel></rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=https%3A//www.peterbe.com/rss.xml"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=https%3A//www.peterbe.com/rss.xml

Home · About · News · Docs · Terms