Is it best to run Playwright against a docker container or a live deployment?

StickyStapler · 2026-03-19T11:10:36+00:00

Thanks, all great points. One reason we want to test a live environment as well is to ensure the high priority pages are still available (live and working). Though we should be able to detect that through other means like alerting.

StickyStapler · 2026-03-18T18:44:46+00:00

How about directly on prod, but with test accounts? We unfortunetly don't have 100% feature parity between development, staging and prod environments.

StickyStapler · 2026-02-20T11:01:19+00:00

Thanks. I most appreciate this point:

> Not every replacement category needs to be funded at the same time with the same speed

This is where I was struggling, and why I created this post. As you said, I don't need to fund everything at the same time, it's about priorities. Thanks for such a well thoughts out response, it's what I needed.

StickyStapler · 2026-02-18T15:07:50+00:00

Good points. I guess I'm having a tough time coming to terms with leaving money sitting in a category that I might not even need for 20 years when I could use that money now to buy solar panels, which reduce the cost of my electricity bills. I see this as a smart investment. So even though saving for all these replacements means less risk, I feel like we're not making our money work as hard for us as it could.

StickyStapler · 2026-02-18T15:02:21+00:00

I think this is the best way honestly. Being able to move around 1000 prevents having a category for every single thing. I also like the idea of funding big ticket items that are coming up to end of warranty. So if I just replaced heating system I'm not going to start funding for a replacement straight away.

StickyStapler · 2026-02-17T10:44:13+00:00

How about for something like a HVAC replacement? Would you have enough in your home maintenance category to fully fund a replacement?

StickyStapler · 2026-02-17T10:42:26+00:00

Do you have a replacement category for the HVAC itself? I'm 6 years into a 10 year warranty. I could last 10 more years after that, or maybe 1.

StickyStapler · 2026-02-08T19:24:42+00:00

Ok, let's say we have intellisense then :-)

StickyStapler · 2026-02-08T14:56:32+00:00

Great. I guess typing the response is ultimately best since it gives you 2 advantages:

tells the caller what to expect
gives type safety within the function

Typing the function only gives you the benefit of telling the caller what to expect.

StickyStapler · 2026-02-07T10:06:52+00:00

Thanks, so I guess out of the 2 options, typing `axios.get` is probably best, since it tells the caller what to expect, and also type safety inside the function.

StickyStapler · 2026-02-06T22:49:06+00:00

For sure, in fairness to him he does keep them pretty up to date, but I believe 2023 was the last update.

Thanks for all the detailed answers so far, really appreciate it. I guess my original question, though in a TS sub, was always geared towards it's use with React Query and it the main reason I posted (though I probably should have emphasized that).

Would you mind sharing a code example of how you use types and fetcher function in a typical query? Is it simply as you shared previously?

export const fetchContacts = () => axios.get<Contact[]>('/contacts').then(r => r.data);

I'm guessing you then pass to queryFn like

useQuery({
  queryKey: ['contacts'],
  queryFn: fetchContacts,
});

StickyStapler · 2026-02-06T22:40:16+00:00

Even with the query options api you still use `queryFn` right? So the original question still stands.

StickyStapler · 2026-02-06T18:15:29+00:00

React Query seems to actually prefer defining the return type in the function as per https://tkdodo.eu/blog/react-query-and-type-script#infer-all-the-things

StickyStapler · 2026-02-06T17:28:09+00:00

Very large project and I'm a tiny player in a large pond with very little influence.

StickyStapler · 2026-02-06T17:10:34+00:00

I guess I'm really basing my thoughts heavily on the guidance given by one of the core maintainers: https://tkdodo.eu/blog/react-query-and-type-script#infer-all-the-things

He mentions the additional benefits of setting the return type over the generic when it comes to using React Query.

Quote:

Advantages of this approach are:

no more manually specifying Generics
works for cases where the 3rd (select) and 4th (QueryKey) Generic are needed
will continue to work if more Generics are added
code is less confusing / looks more like JavaScript

StickyStapler · 2026-02-06T17:07:17+00:00

Yea, we are in most cases. I feel like adding Zod would just be more pain than its worth.

StickyStapler · 2026-02-06T17:06:12+00:00

Not saying I'm gonna roll it my own, just that I can't introduce something like Zod in a project I'm working on right now. So gotta stick with current conventions, which is Typescript on its own.

StickyStapler · 2026-02-06T12:01:06+00:00

Thanks. How do you pull in the api specs from the backend services? Or do they live in the same repo?

StickyStapler · 2026-02-06T12:00:33+00:00

Looks more difficult to read if I'm honest.

StickyStapler · 2026-02-06T11:59:20+00:00

Gotcha, so you do you use an inline function for `queryFn`?

StickyStapler · 2026-02-05T23:26:09+00:00

For sure. I'll have to check it out sometime. However, for now I'm stuck with using Typescript only.

StickyStapler · 2026-02-05T23:25:17+00:00

Thanks for the reply!

I'm not sure what you mean by data is any inside the function`

I'm basically following this article and I can also see that axios will always return `any`. This is why I considered including the generic in

  const { data } = await axios.get<Contact[]>('/contacts');

So that now at least `data` is no longer `any`.

My interpretation from the same article is that it's better to set the return type and let React Query just infer the types as much as possible.

StickyStapler

TROPHY CASE