warn when creating a client without url #512
Conversation
What would you opt for? I'm pretty positive about developer-friendly warnings for less-obvious things that can result in crashes (obscure crashes for that matter). We shouldn't take it too far but |
|
I like the idea but I think those who want to avoid running into runtime errors like this should use static typing - we have TS types enforcing this. Maybe a guide on how to get static typing enforcement on a JS code base (basically just creating a tsconfig) is the way to go? |
|
@andyrichardson this is just a runtime warning, so I think conceptually it’s fine. I think it’s pretty ok given that we can’t enforce every type (full runtime checking in development would just be tedious to add or generate and wouldn’t add much value imho) but my problem with this is, we may as well throw in development? It’s not like this code is going to continue working without a url 😅 |
|
@kitten I'm not too opinionated either way, my thinking is related to the cost of maintaining both static and runtime type safety (and keeping them in sync). Would be awesome if we could respond to issues with "hey, looks like you're not doing any type checking, here's a resource on how you can make sure these kind of issues don't happen on Urql and other type-safe libraries (without re-writing your app in typescript) - https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html" |
|
To be fair, I think the issue this spawned out of is here: FormidableLabs/next-urql#24 where an environment variable wasn't coming in correctly. In this case, static typing wasn't the issue (the user's codebase is in TS), but rather an env variable not getting swapped in properly at runtime. This is definitely a good case for this kind of warning, since the error message otherwise ( |
|
@parkerziegler I'm fully agreeing with you. Going to merge this for now |
This stems from a twitter conversation where the undefined url would lead to an error in a minimalistic fetch-shim.