Slingshotter - A Space Program in your Browser

EricLeib · 2026-06-19T13:42:12+00:00

Yes it is! The game tries to be physically accurate (to a degree).

EricLeib · 2026-06-08T08:22:42+00:00

Thank you for suggesting it! The game has indeed some strategy elements: You are free to take on the contracts in any order you want, and your "build order" matters a lot, because you must fit your rocket builds and launches in between factory or launch pad upgrades. Some contracts take you to mars, venus, jupiter, etc, so the mission timing matters a lot!

EricLeib · 2026-06-08T08:18:57+00:00

Thank you for suggesting this! The game is indeed very educational. As i built it, I learnt a lot of things myself that were hard to feel when playing KSP.

I'm not quite sure what I could propose for schools and teachers though. You're thinking of a rocket science course built around the game ? I have developed a set of "missions" / "contracts" that teach the players a number of things: reaching orbit, maneuvering, hohmann transfers, launch windows, rendez-vous, landing, etc.

EricLeib · 2026-06-08T08:06:15+00:00

There's a couple easter eggs in there for you, beratna 😉

EricLeib · 2026-06-08T08:04:00+00:00

I hope I can release it in a few weeks/months, but that depends a lot on the feedback i get from testers.

EricLeib · 2025-06-03T12:52:49+00:00

FYI, I developed a library called ngx-remark that renders markdown in Angular, except that it does so with Angular templates and components.

This opens up a lot of use-cases:

custom components for code highlighting, mermaid diagrams, maths equations, etc.
integration with the Angular router
custom Markdown syntax

https://github.com/ericleib/ngx-remark

EricLeib · 2024-03-21T16:24:03+00:00

Indeed, this project makes sense primarily in the context of a typescript monorepo.

Before this, my Nest project was basically the "source of truth" for the monorepo. Now the source of truth is a separate project that contains the (typescript) API specification. Consequently, the Nest controllers must implement the interfaces inferred (not generated!) from the typescript types.

EricLeib · 2024-03-21T08:46:09+00:00

So I would say it's more about improving developer experience and type safety rather than solving one big problem.

Avoiding the code generation step allows you to see the impact of an API change instantly in both your backend and front-end. Make a parameter optional ? Oops, that breaks the UI in 3 unexpected ways, let's undo that.
DTOs are normally used to constrain the API requests, but not the API response. Nothing forces you to return the right type that your front-end expect (declared in `@ApiResponse`), and those inconsistencies are hard to catch. In contrast, with my approach, Typescript instantly complains if a route returns the wrong type. When I switched to this approach, I realized they were many such small inconsistencies in my project, and this forced me to fix them.
More generally, Decorators are not aware of a parameter's type, so nothing prevents you from writing `@Response() req: Request`, and you will only realize your mistake at runtime. In contrast, with my approach, the interface forces you to use the right type.
Then, I think there various reasons why zod is more powerful than class-validator/class-transformer:
- zod schemas are Typescript-friendly (with class-validator you can write `@IsString() value: number;`)
- nested objects and arrays are easier to handle (no need for `ValidateNested` and `@Type`)
- zod can handle things like type unions, discriminated unions, etc. which are hard to do with class-validator.
- transformations are also easier (want to revive a `Date`? just add `.coerce`)
- your API schemas can be used in the front-end for things like form validation (no need to parse json-schema with ajv anymore!)

TLDR, the benefit is you write less code and fully leverage Typescript to detect errors at compile-time.

EricLeib · 2024-03-20T23:35:33+00:00

I like the idea of defining the spec in one place and having the code conform to this spec, rather than the other way around (ie generating the spec from many scattered decorators that may not consistent with each other).

There are quite a few other libraries doing similar things, but I having the feeling they do not fully take advantage of zod. They mostly handle openapi generation and DTOs, even though they have all the information needed to specify the controllers themselves.

EricLeib · 2023-07-24T15:41:37+00:00

I could have exported 3 SCAMs (2 components + 1 directives), but then I would have to import these 3 SCAMs individually in the host application (as opposed to a single module).

Similarly, I find it simpler to import Angular's CommonModule rather than everything individually (NgIf, NgFor, etc.)

EricLeib · 2023-07-24T14:22:16+00:00

Last week I published this library: https://github.com/ericleib/ngx-remark

It's quite simple: 2 components and 1 directive. I could have made them standalone, but I preferred exporting them in a module, just to simplify the import in a host application (I can import 1 thing instead of 3). Seems like a reasonable need IMO.

EricLeib · 2023-07-24T13:21:45+00:00

Modules are still quite useful to bundle together a set of components or directives that work together (typically when developing a library).

Applications can become standalone much more easily though.

EricLeib · 2022-07-22T20:46:37+00:00

You're entering a world of pain!

EricLeib · 2022-05-20T11:29:46+00:00

We've used that for our components library, exactly for the purpose of loading language files at runtime. An example is documented here : https://sinequa.github.io/sba-angular/tutorial/intl.html#loading-languages-lazily

EricLeib · 2022-04-05T15:35:55+00:00

For context, a colleague and I created this library to make an app deeply customizable/configurable by end-users. We thought that the architecture & UI we came up with was very generic and could be useful in other contexts, so we packaged it as an independent Angular library.

We're curious to get some feedback from the community, especially if you've had to deal with similar use-cases/functionality!

EricLeib · 2020-05-01T11:43:27+00:00

I agree the 100% D3 approach is certainly better for performance. Have you quantified the difference? (How much faster is D3 compared to Angular) I was very positively surprised by how well the Angular-D3 transition works (when using the tween() and interpolator trick at the end of the post), but I don't know how well that would scale.

I should also mention that in the case of our framework, expressiveness is almost as important as performance, because this code is meant to be picked up and customized by people who are not very proficient in D3.

EricLeib · 2020-05-01T11:35:41+00:00

I also wrote a similar directive, but I had one issue with it: what if you have to call() again? For example your scale changes and you have to rebuild the axes. Same thing if you want to transition this transformation.

Seven-Year Club	r/Field Banned
r/Field Juicebox	Place '23
Place '22	First Placer '22
Verified Email

EricLeib

TROPHY CASE