Echo JS 0.11.0

<~>

tracker1 comments

tracker1 1268 days ago. link 1 point
TLDR Url: https://github.com/mocks-server/main/tree/master/packages/config

Would be useful if you're writing configurable modules that will be used by other projects.

Aside: Wouldn't use this for applications/services as I tend to prefer environment variables, and load ~/.env with find-up directory tree searching from cwd.  .env for local use, defaults for local dev and environment injection on deployed servers.
tracker1 1269 days ago. link 1 point
Surprised this isn't using shadow dom for display, but cool all the same.
tracker1 1271 days ago. link 1 point
Many of these are arguable as the hinting system from typescript in modern editors (vs code, jetbrains, etc.) are able to determine return types, just as an example.  Of course this can be argued of linting generally speaking, so it's okay as options.

My biggest niggle with TS lately, is that tsc and deno have different import rules... for deno, you must use the extension, for tsc you must not, and I really wish tsc could be changed via an option to match the deno behavior, which I feel is more correct.  I think being able to share modules between the node/esbuild ecosystem and deno is going to become ever more important in the next couple years... especially if you can just share the ts source directly instead of built js modules with separate definitions.
tracker1 1274 days ago. link 1 point
Personally, I tend to prefer a feature oriented structure... where each feature is where directories are separated, and subdirectories created as necessary.

Each feature containing it's own context/state, components, tests and data fetching...  this can be registered with core routing and used in concert with more generalized components/wrappers.  It also tends to make it easier to break down into more of a micro-ui pattern if needed.

You can use redux-micro-frontend for state management in concert with exposing React and your UI component library of choice as global patterns from the start.  Again, easier to break things up later.

Just my own $.02
tracker1 1276 days ago. link 2 points
Not to be pedantic, but this isn't an implementation, it's a usage demonstration... an implementation would be a shim/shiv that adds it to String.prototype if it isn't present.
tracker1 1276 days ago. link 1 point
This is closer to where I'm coming from... when referencing articles, or interfaces, TS has pretty much become the more ubiquitous standard.  I'm fine with plain JS, but TS makes things a bit more clear in typical use... especially when explaining certain interfaces and libraries to make return types clear, etc.
tracker1 1276 days ago. link 1 point
Wonder if something like this could work with Microsoft's new Windows Terminal or Tabby.
tracker1 1278 days ago. link 1 point
I can't help but wonder, what is the overhead to manage such a beast across all the components used in an application using this approach.
tracker1 1281 days ago. link 1 point
While I know that it's not expressly required, but the article, and MobX itself would be easier to understand in the context if the code samples used TypeScript.

In some cases, it's less than clear with regards to usage.  Just my own $.02 ... I often prefer to use straight JS in practice, and sometimes find TS annoying, but it definitely helps in understanding, at least that's my take.

Anyone else have thoughts on this?
[more]