exodus Comments - Answer Overflow

exodus

Explore posts from servers

•Created by FelipeEmos on 8/9/2023 in #questions

Why Theo doesn't talk about Ionic/CapacitorJS? [Capacitor vs React Native]

Ahh my mistake! I do plan on trying solid soonish, just haven’t had a chance to do a side project yet. Just read the docs from a hobbyist perspective.

31 replies

TTCTheo's Typesafe Cult

•Created by FelipeEmos on 8/9/2023 in #questions

Why Theo doesn't talk about Ionic/CapacitorJS? [Capacitor vs React Native]

But now I'm shifting over to NX and am using index.ts in the root of my libs to encapsulate internals and declare a public api for each lib

31 replies

TTCTheo's Typesafe Cult

•Created by FelipeEmos on 8/9/2023 in #questions

Why Theo doesn't talk about Ionic/CapacitorJS? [Capacitor vs React Native]

Working with Vue now and it's currently my go to, as it has IMO the best reactivity primitives of any framework out there (basically SolidJS signals with the option of having deeply reactive proxies). Creating reactive and performant applications is a breeze. The only pain point I'm running into is that I'm actually missing Angular's modules. Having the ability to encapsulate module internals was actually really useful in hindsight

31 replies

TTCTheo's Typesafe Cult

•Created by FelipeEmos on 8/9/2023 in #questions

Why Theo doesn't talk about Ionic/CapacitorJS? [Capacitor vs React Native]

Angular is actually getting to a decent place. Signals are ironing out a lot of the issues I had with it. Not sure what the state of AnalogJS is these days, but that was my last pain point: webpack sucks. If it works well with Vite nowadays then I'd honestly consider Angular again for a heavyweight application of moderate to large scale.

31 replies

TTCTheo's Typesafe Cult

•Created by FelipeEmos on 8/9/2023 in #questions

Why Theo doesn't talk about Ionic/CapacitorJS? [Capacitor vs React Native]

Great writeup! Honestly, I think SSR is way oversold in the tech influencer space. CSR is perfectly adequate, far simpler, and cheaper for most use cases. Depends what you're doing obviously...if you're creating a content heavy site then SSR may be more beneficial, but then I'd question why not go with something like Astro. The desktop replacement apps, CSR all the way.

31 replies

TTCTheo's Typesafe Cult

•Created by Perfect on 2/4/2023 in #questions

Battling TypeScript Types

AWesome. Yeah I should have pointed out that Record is usually something you reach for for dynamic keys...i.e. something that you don't know at compile time. Sorry, I don't know why i didn't go that route first

50 replies

TTCTheo's Typesafe Cult

•Created by Perfect on 2/4/2023 in #questions

Battling TypeScript Types

Assuming there are known keys for the items in cost, then it would be good to define them.

interface Explosive {
  name: string;
  cost: Record<Material, number>;
}

type Material = "sulfur" | "charcoal" | "frags"

interface Explosive {
  name: string;
  cost: Record<Material, number>;
}

type Material = "sulfur" | "charcoal" | "frags"

Or maybe Material is another object you'd like to define

interface Explosive {
  name: string;
  cost: Record<typeof Material[name], number>; //I think this is right
}

interface Material {
  name: MaterialName 
  cost: number
}

type MaterialName = "sulfur" | "charcoal" | "frags"

interface Explosive {
  name: string;
  cost: Record<typeof Material[name], number>; //I think this is right
}

interface Material {
  name: MaterialName 
  cost: number
}

type MaterialName = "sulfur" | "charcoal" | "frags"

Alternatively, you can use an enum, even though these are a bit out of style today. They're still probably more appropriate in this case:

interface Explosive {
  name: string;
  cost: Record<MaterialName, number>; //I think this is right
}

enum MaterialName {
  SULFUR = "sulfur",
  CHARCOAL = "charcoal",
  FRAGS = "frags"
}

interface Explosive {
  name: string;
  cost: Record<MaterialName, number>; //I think this is right
}

enum MaterialName {
  SULFUR = "sulfur",
  CHARCOAL = "charcoal",
  FRAGS = "frags"
}

You can get as crazy as you want, really. Just think of any place where your IDE doesn't provide you proper autocompletion, and then see if there might be a better way to define your types. In this case, Record<string, number> is probably too broad. If you replace string with a union or enum, then you'll actually get autocomplete and type checking when you try to add a property to cost.

50 replies

TTCTheo's Typesafe Cult

•Created by exodus on 2/4/2023 in #questions

Astro as a multi-app host (i.e. microfrontends)

Keeping in mind apps will ONLY be SPA. No need for SSR at all in this case.

6 replies

TTCTheo's Typesafe Cult

•Created by Perfect on 2/4/2023 in #questions

Battling TypeScript Types

for complex types like this, you should declare the type rather than infering. This is a good case for types/interfaces. I'll go with Record<string, number> for now for cost, but you really should also define these in a union type or enum, assuming their names are known ahead of time.

interface Explosive {
  name: string;
  cost: Record<string, number>;
}

// or if you prefer
type Explosive = {
  name: string,
  cost: Record<string, number>,
}

export const boom: Explosive[] = [
  {
    name: "Handmade Shell",
    cost
    ..etc
  }
]

interface Explosive {
  name: string;
  cost: Record<string, number>;
}

// or if you prefer
type Explosive = {
  name: string,
  cost: Record<string, number>,
}

export const boom: Explosive[] = [
  {
    name: "Handmade Shell",
    cost
    ..etc
  }
]

This kind of sounds like a game, so I'd probably opt for interfaces over types. Games are one situations where Object Oriented patterns can be useful

50 replies

TTCTheo's Typesafe Cult