exodus
exodus
Explore posts from servers
NNuxtTTCTheo's Typesafe Cult
PostsComments
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]
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
Created by exodus on 1/13/2023 in #questions
Typesafe backend stack
I think for prod I'd still probably take the NestJS route since the DX ends up being about as nice. But I'll leave it up to the team...they might not be really comfortable with the dependency injection mechanisms.
43 replies
TTCTheo's Typesafe Cult
Created by exodus on 1/13/2023 in #questions
Typesafe backend stack
I can totally see myself using zodios for personal projects. May consider it here, but I need a reasonably easy path to eject. I like tRPC, but I do wish it was just built on top of REST. Custom communication protocols come and go, and a language specific protocol isn't really well suited for the long-term. Zodios looks like it addresses that.
43 replies
TTCTheo's Typesafe Cult
Created by exodus on 1/13/2023 in #questions
Typesafe backend stack
Hmmm not bad
43 replies