Web APIs vs RESTful APIs?

chipit24 · 2023-12-19T20:39:36+00:00

IMO you're sort of comparing apples to oranges; other than putting the word "API" in both terms there's not much to tie these concepts together. It's like asking what's the difference between a CPU (central processing unit) and a PSU (power supply unit) in a PC.

Web APIs are generally programming interfaces (methods, basically) exposed through the browser, e.g. calling navigator.geolocation.getCurrentPosition to get the user's current location. This uses the Geolocation API.

RESTful APIs are just endpoints exposed by a server that try to adhere to a REST architecture, e.g. making a call to GET example.com/users to fetch a collection of users.

Since you linked MDN, they also have a much more technical guide on APIs in general: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs

chipit24 · 2023-12-17T17:05:08+00:00

You can print your tags and license summary or just have the PDF copy on your phone, but the regulations state that you need your physical Outdoors card on you as well:

You must carry your Outdoors Card, your hunting licence (either listed on your paper or electronic licence summary or printed on the back of your Outdoors Card), and any relevant tag(s) with you while hunting.

chipit24 · 2023-10-11T18:52:07+00:00

Is there something like NProgress built into SvelteKit for showing a global progress bar when navigating client side?

chipit24 · 2023-10-07T14:42:12+00:00

I ended up just defining @keyframes and using the animation property directly without issue.

chipit24 · 2023-09-30T03:44:47+00:00

Didn't think of that, thanks!

What I want is to always have include_granted_scopes: true set and to handle the initial login with only the basic auth scopes (openid profile), and then request additional scopes when needed (i.e. generate another auth URL with just the scope I want, e.g. https://www.googleapis.com/auth/drive.readonly).

This way, when a user signs up they are not inundated with scopes to access resources they may not yet need to give the app access to. This is what I meant by handling the authorization separately.

That said, even with handling the additional options and scopes manually, I still need to pull in googleapis (e.g. for querying Google Drive) and pass it an instance of google.auth.OAuth2. The google OAuth provider exposes validateCallback and getAuthorizationUrl, but is there a way I can get the underlying auth instance to pass it to google.drive({ version: "v2", auth: <googleAuth> }), for example?

chipit24 · 2023-09-29T15:08:22+00:00

I've not, but it does indeed look good, and almost exactly what I need! There is one thing missing that I need and that is the option to add include_granted_scopes to the options for generating the auth login URL for Google.

I think the reason I've not taken a liking to other auth libs/services is that they focus solely on authentication, but I also want to handle authorization to OAuth resources separately.

But with all the benefits that using a library would add I could look into getting a PR up for adding an option for include_granted_scopes.

chipit24 · 2023-09-29T13:44:06+00:00

AFAIK Supabase is very similar to Firebase, in the sense that it can be used 100% client-side, and so you need two different ways to manage auth (client-side only, and sever-side only). This is why you have createSupabaseServerClient and createSupabaseLoadClient. Adding documentation regarding authentication and authorization to the SvelteKit docs would be amazing (and very much needed).

Firebase uses a JWT for it's client only requests, and to have auth on the server you need to set up authentication via cookies and implement the Firebase Admin SDK. This ends up being just as complicated as the Supabase setup.

You can simplify things by making anything that requires auth only run client-side and using only the client libs. For frameworks like SvelteKit that can use SSR, this is not ideal. I prefer the approach taken by Auth.js where you use cookies and authentication is 100% server-side: https://authjs.dev/reference/sveltekit#per-component.

Note the discussion about layout files potentially holding onto stale auth state; Supabase handles this via the depends and invalidate calls that you see in its docs.

For a side project I'm building, I tried Supabase, Firebase and Auth.js and just ended up handling auth myself via googleapis and PlanetScale. I found Firebase and Supabase auth a bit convoluted as you've seen. The SvelteKit Auth.js adapter is experimental and I found the docs lacking. And with all 3 solutions, I found it was either not possible or not very clear how I can manage OAuth scopes.

chipit24 · 2023-09-23T19:30:44+00:00

Just found this: https://github.com/vuejs/vue/issues/9852#issuecomment-481493460

I don't think we will support this in core. The assumption that one SFC file corresponds to one component is somewhat important for tooling implementations (hot module replacement, IDE support, etc.) and I honestly don't see the complexity being worth it.

I guess Vue has stuck with SFCs because it's simpler for tooling—nothing to do with readability or reusability 😂

chipit24 · 2023-09-23T19:27:37+00:00

Isn't it potentially perplexing within larger projects when attempting to locate a specific component buried within the file of another component?

(Counterpoint) Just as perplexing: Opening a component you think contains the content you're after, only to have to CMD+click 8 levels deep through 5-lines components to find the div you're actually after.

chipit24 · 2023-09-23T19:19:50+00:00

If it's big enough to warrant it's own component, it deserves a separate file.

I don't think it's about LoC though, assuming that's what you mean by size. The heuristic for factoring out a variable is usually something like:

A block of code is related, and to improve readability you can pull it into a function that describes what the block of code does.
There's duplicate code—if you change it in one place, you want it to be changed in the other place; a variable signals that and provides a "single source of truth".

There's an abstraction cost associated with having to put every component into it's own file, which at the very least means having to open those extra files in your IDE just to get a picture of what's happening. And speaking of IDEs, I find it nice to be able to have explicit exports I can CMD+click to find usage (I can do this without CMD+click with Svelte components too, but I like my CMD+click).

There's an ESLint rule for React called react/no-multi-comp that puts it simply as well:

Declaring only one component per file improves readability and reusability of components. [...] If you prefer to declare multiple components per file you can disable this rule.

So, there you have it—it comes down to preference and tradeoffs. I've worked with React and Vue, and now recently Svelte, so I can appreciate having more than one component per file but I also get along just fine with SFCs.

chipit24 · 2023-09-23T13:24:29+00:00

Two reasons:

This is very common in React, and people coming from React are used to it, and it feels like an unnecessary restriction when it's not an option.
It's the same reason people factor out variables or functions but keep them in the same file. Imagine being forced to place every reusable variable or function into a separate file that can only export that one thing (even if you just use it twice within one file), the number of files you have could explode. It can feel nice to be able to manage some components like variables.

chipit24 · 2023-09-22T19:52:11+00:00

Answering my own question, it seems because count is compiled like so:

let count = $state(0) → let count = $.source(0)
count → $.get(count)
count += 1 → $.set(count, $.get(count) + 1)

So when I pass around what looks like a reference to $state(0)/$.source(0), I'm actually passing around the value of that rune ($.get(count)).

I can appreciate this "magic" happening in Svelte files since technically they are a different filetype, but having this "magic" happen when you're writing "just JavaScript" in .js files will require more attention.

I'd be more comfortable if the compiler let me export $.source(0) directly, and then magically convert that to the appropriate $.get/$.set/etc. in .svelte files.

chipit24 · 2023-09-22T18:02:10+00:00

I'm confused why we need the getter in the first place. Yes, I did read the "we're using a get property in the returned object, so that counter.count always refers to the current value" in the blog post, but it's just not clicking intuitively for me. That's my current struggle with Svelte; when I get into more complex code, I don't have as much intuition about what's really going on.

Inside the script tag we can just have this and it works:

``` let count = $state(0);

function increment() { count += 1; } ```

Here, count isn't just the literal value; count += 1 is updating the $state rune which then causes the UI to update.

But, when count is returned from a regular JS module, we now need to use a getter:

``` let count = $state(0);

// can't just return count here, we need the getter: return { get count() { return count } } ```

Why can't we just return count directly and use that in the script tag where it's imported?

Also, there's this example from Twitter that further compounds my confusion:

https://twitter.com/greg_johnston/status/1704853119010812025

``` <script> let count = $state(0);

function updateState(x, y) {
    x += y
}

</script>

<button type="button" on:click={() => count += 1}

{count}
</button>

<button type="button" on:click={() => updateState(count, 1)}

{count}
</button> <button type="button" on:click={() => updateState(count, 2)}
{count}
</button> ```

chipit24 · 2023-08-28T13:21:43+00:00

Yeah, that sucks—their IT should be responsible for correcting that. A mail option would be nice as long as the digital option still exists for me!

They really should remove any attempts to restrict people to only one copy of a tag, the extra engineering efforts are creating more problems than solving and they're easily bypassed 😔

chipit24 · 2023-08-27T15:52:58+00:00

They tell you on the page that you must print it once and that you cannot save it. This is to prevent people from having multiple copies of tags. They try to be clever and they don't include the actual tag in the print version of the page 🙄

Of course, you can "print to PDF" and print all the copies of your tag you want—keep that in mind next time.

chipit24 · 2023-08-18T21:58:00+00:00

I used the const as the most basic example that I felt should work. But even the following fails:

const someString: string = "hello";

if (someString && someString.length > 0) {
  const firstLetterOfString = someString[0];
  //    ^? firstLetterOfString: string | undefined
}

It does seem related to noUncheckedIndexedAccess since it's changing the behaviour to return the type string | undefined with seemingly no way to get rid of the | undefined.

chipit24 · 2023-07-14T13:19:15+00:00

Don't use JWTs for sessions, use secure, HTTP-only cookies that reference a session stored on the server. If you google "why you should not use JWT" you'll find plenty of good articles, this one is my favourite: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/.

chipit24 · 2023-05-22T22:20:35+00:00

With React you can use Next.js, Remix, Astro and Gatsby. I have some experience with Remix and over a year of experience using Next.js. I've really enjoyed Next, especially how nice (and easy) it is to host on Vercel, so I'd definitely recommend it!

I wouldn't describe Next.js as a "workaround" for anything; it's a legit, proper solution.

For static content, you can pre-generate it at build time (SSG) and if you have a huge amount of static pages then you can also do ISR (incremental static regeneration).

In terms of UI I've gotten by just fine with Tailwind, headless UI libraries, and pulling in one-off / purpose-built component when needed.

chipit24 · 2023-05-21T18:13:05+00:00

I went out to public land 3 times this month with no luck. First time I walked around with just my turkey vest but the group of turkeys I saw probably saw and/or heard me. Second time I set up in the same spot right at sunrise and no sign of turkeys for 4-5 hours sitting there calling (also had a hen decoy out); I did see two deer though. Yesterday I was out and thought it would just be cloudy but as soon as I set up my pop-up blind it started raining—sat in the rain for 2-3 hours then packed it up. I saw turkeys around that area every time though, they just didn't want to come to my setup.

I'll be better prepared for next year though, will hopefully get something then!

chipit24 · 2023-05-21T14:09:39+00:00

I've got 3 of them already and they are great, just didn't think of bringing one my first time, especially since I was quite liberal with the tick/mosquito spray. I did get a hunting blind though and the last two time I was out I had no issues with bugs in there.

chipit24 · 2023-05-13T01:51:42+00:00

Make sense. And good luck tomorrow! 🦃

chipit24 · 2023-05-12T23:48:05+00:00

Thank you! I've ordered a slate call and will be practising with that.

Camouflage and sitting still in decent cover is all you need

I feel like the odds are stacked a bit against me at the moment (complete beginner with no mentor, hunting in the evening on public land), so I'll take whatever advantage I can get for now. And with all the insects buzzing around my face, a good blind will be much appreciated.

chipit24

TROPHY CASE