4 ms·

I’ll bite. Say you have a singleton service class that needs to be accessed throughout your SPA; where would you instantiate and keep this?

mythz 5y ago
Typically you'd just export: export const singleton = new Singleton() and import it like any other symbol, e.g: import { singleton } from './providers'
- pfooti 5y ago
  What happens when that singleton has dependencies? And they have dependencies? Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env. Not saying that these are impossible, but at some point you either end up reinventing dependency injection, or you end up with all the problems that cause people to invent dependency injection.
  - mythz 5y ago
    > What happens when that singleton has dependencies? And they have dependencies? Everyone exports/imports their deps the same way as everything else. > Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env. Having different environment config is standard feature in most JS FX Apps, if it changes at runtime it's maintained as App state with any changes typically propagated reactively. I've yet to run into any issue that I needed an IOC for in a client JS App (despite always using them for backend C# Servers) but they're unnecessary in JS, our Angular templates are the only ones that use them, all other premier JS FX's happily get by without them.
    - Oddskar 5y ago
      So in other words you have TERRIBLE separation of concern. This was my point exactly.
      - mythz 5y ago
        Lol, you have more freedom to logically structure your code base when you’re not beholden to forced EE abstractions. and to repay the unwanted commentary you have a bloated, overly abstracted tech-debt ridden liability that’s perfectly suited for Angular, congratz.

mythz 5y ago

Typically you'd just export: export const singleton = new Singleton() and import it like any other symbol, e.g: import { singleton } from './providers'

pfooti 5y ago
What happens when that singleton has dependencies? And they have dependencies? Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env. Not saying that these are impossible, but at some point you either end up reinventing dependency injection, or you end up with all the problems that cause people to invent dependency injection.
- mythz 5y ago
  > What happens when that singleton has dependencies? And they have dependencies? Everyone exports/imports their deps the same way as everything else. > Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env. Having different environment config is standard feature in most JS FX Apps, if it changes at runtime it's maintained as App state with any changes typically propagated reactively. I've yet to run into any issue that I needed an IOC for in a client JS App (despite always using them for backend C# Servers) but they're unnecessary in JS, our Angular templates are the only ones that use them, all other premier JS FX's happily get by without them.
  - Oddskar 5y ago
    So in other words you have TERRIBLE separation of concern. This was my point exactly.
    - mythz 5y ago
      Lol, you have more freedom to logically structure your code base when you’re not beholden to forced EE abstractions. and to repay the unwanted commentary you have a bloated, overly abstracted tech-debt ridden liability that’s perfectly suited for Angular, congratz.