Cody Bontecou Posts - Answer Overflow

Cody Bontecou

Explore posts from servers

NNuxt KKinde

Posts Comments

NNuxt

•Created by Cody Bontecou on 5/9/2024 in #❓・help

typedPages not providing types

3 replies

NNuxt

•Created by Cody Bontecou on 5/6/2024 in #❓・help

Test Utils + Vitest + MSW - potential caching issue

I'm using a combination of "@nuxt/test-utils": "^3.12.1",, "vitest": "^1.5.0", and "msw": "^2.2.14", to test my Nuxt application. Everything works great, except I'm running into an issue when attempting to mock a specific http request using MSW (https://mswjs.io/):

  it('should retry fetching the next match after a delay', async () => {
    mswServer.use(
      http.get(lolesports.GET_SCHEDULE_ENDPOINT, () => {
        return new HttpResponse(null, {
          status: 401,
        })
      })
    )

    const setTimeoutSpy = vi.spyOn(global, 'setTimeout')
    await getNextMatchFromLoop()

    vi.advanceTimersByTime(intervalTimes.fiveSeconds)

    expect(setTimeoutSpy).toHaveBeenCalledTimes(1)
  })

  it('should retry fetching the next match after a delay', async () => {
    mswServer.use(
      http.get(lolesports.GET_SCHEDULE_ENDPOINT, () => {
        return new HttpResponse(null, {
          status: 401,
        })
      })
    )

    const setTimeoutSpy = vi.spyOn(global, 'setTimeout')
    await getNextMatchFromLoop()

    vi.advanceTimersByTime(intervalTimes.fiveSeconds)

    expect(setTimeoutSpy).toHaveBeenCalledTimes(1)
  })

In this case, I'm trying to do a one-off network override (https://mswjs.io/docs/best-practices/network-behavior-overrides). This doesn't actually override the HTTP request, and instead provides the response from my initial mock that is passed to my MSW server. I'm happy to get deeper into the details if you're interested, but the question I have is related to caching. This problem is discussed a few times in the MSW github (https://github.com/mswjs/msw/issues/694#issuecomment-860570247), and the solution tends to be caching-related. I haven't been able to find anywhere to disable or force-reset the vitest or nuxt test-utils cache besides https://vitest.dev/config/#cache, which had no effect.

4 replies

NNuxt

•Created by Cody Bontecou on 5/2/2024 in #❓・help

Where to deploy with long-polling functions

I'm a bit confused where Nitro hangs out in the deployment space and how these deployed environments manage setInterval alongside Nitro endpoints. I have a function that runs every 10 seconds and is currently managed in Nitro like so:

export default defineEventHandler(async event => {
  try {
    let intervalId: NodeJS.Timeout
    const intervalTime = 10000 // 10 seconds in milliseconds

    intervalId = setInterval(() => {
      getLiveGameData(intervalId)
    }, intervalTime)
  } catch (e) {
    const error = createError({
      statusCode: 500,
      statusMessage: `Something went wrong with lolesports: ${e}`,
    })
    return sendError(event, error)
  }
})

export default defineEventHandler(async event => {
  try {
    let intervalId: NodeJS.Timeout
    const intervalTime = 10000 // 10 seconds in milliseconds

    intervalId = setInterval(() => {
      getLiveGameData(intervalId)
    }, intervalTime)
  } catch (e) {
    const error = createError({
      statusCode: 500,
      statusMessage: `Something went wrong with lolesports: ${e}`,
    })
    return sendError(event, error)
  }
})

Does this run for a few seconds every interval, or is the setInterval creating a long-running process that is never killed until the setInterval is killed using clearInterval(intervalId)? I imagine the latter would get expensive quickly in a serverless environment. Or, am I overthinking this? My understanding is serverless is ideal for short-running bits of code, not for long-running processes, and in fact, serverless providers tend to have a time-limit on long-running code. Is there a more ideal way to deploy a Nuxt application that utilizes Nitro extensively and doesn't depend on a serverless backend?

7 replies

NNuxt

•Created by Cody Bontecou on 4/11/2024 in #❓・help

What is the recommended route to using a 3rd-party composable that relies on the window object?

I'm playing with vue-plaid-link and ran into issues until I dug into the source and saw this line:

const next = createPlaid(
    {
        ...options.value,
        onLoad: () => {
            iframeLoaded.value = true
            options.value.onLoad && options.value.onLoad()
        },
    },
    window.Plaid.create
)

const next = createPlaid(
    {
        ...options.value,
        onLoad: () => {
            iframeLoaded.value = true
            options.value.onLoad && options.value.onLoad()
        },
    },
    window.Plaid.create
)

Specifically, the window.Plaid.create. I was able to get this to working by disabling ssr in my nuxt config, but this is not ideal. I'd prefer to continue using ssr, while also being able to use this library. What is the current recommended way of handling this? Is it plugins? Checking against the window object before using the composable?

4 replies

NNuxt

•Created by Cody Bontecou on 2/28/2024 in #❓・help

Is there a useFetch alternative that allows me to call the server function without a string?

I might call a server endpoint like so:

const { data: userData } = await useFetch<User>('/api/test')

const { data: userData } = await useFetch<User>('/api/test')

I'd like to do something more trpc-like, allowing me to avoid the use of strings. Is this currently possible?

3 replies

NNuxt

•Created by Cody Bontecou on 2/28/2024 in #❓・help

E2E Type safety: What am I missing?

I'm exploring e2e type safety and am curious what I am missing. Here's my server route:

// server/api/test.ts
import type { User } from '~/types/user'

export default defineEventHandler(() => {
  return { test: '0' } as User
})

// server/api/test.ts
import type { User } from '~/types/user'

export default defineEventHandler(() => {
  return { test: '0' } as User
})

And I consume this on the client like so:

<script setup lang="ts">
import type { User } from './types/user'

const { data: userData } = await useFetch<User>('/api/test')
</script>

<script setup lang="ts">
import type { User } from './types/user'

const { data: userData } = await useFetch<User>('/api/test')
</script>

I have to explicitly state the expected return type from the useFetch hook. I assumed this would be inferred from the backend. Here's a reproduction: https://github.com/CodyBontecou/nuxt-e2e-types

1 replies

Gaming

Programming