Echo JS 0.11.0

<~>

tracker1 comments

tracker1 1579 days ago. link 1 point
While the default "Deno Deploy" from the Deno company will be a paid service, there will be self-host solutions that will match and I wouldn't be surprised if CloudFlare and other providers become viable solution targets as well.

I'm a bit mixed on the likes of Firebase, Fauna and Dynamo direct client access and security, it does seem like a relatively cool in the box approach.

I don't think this process has been posted about, and I will limit any future posts to after alternative targets are available and/or that target other platforms.

https://deno.com/deploy
tracker1 1580 days ago. link 1 point
Why would one use this over just using core-js or es-shims version(s)?
tracker1 1580 days ago. link 1 point
On the "All promises fulfilled" part.

    export const someFn = () => 
      new Promise(() => {
        // Hahahahaha
      });
tracker1 1586 days ago. link 1 point
Mostly agree... it tends to come down to managing state, validation, errors and submission as a whole, and rather than using bespoke code for each form using a library that combines these things in a cohesive way.

I'm usually using material-ui and redux, so there's those extra bits to wire in as well.

I'm not a fan of "list" posts in general, especially those that don't provide a method of selection, but the post and comments at least mention a variety of libraries for this, and being a react list it's at least a more narrow focus.
tracker1 1592 days ago. link 1 point
Should consider separating the SpeakEasy JS talks into a separate YouTube channel.

Also, please add a [SpeakEasy JS] prefix to future video posts. :-)
tracker1 1593 days ago. link 1 point
I don't, but a team at the company I work at is using a micro-ui architecture, not bit.

As for the bit articles, I tend to remove the bit articles that aren't technical on other topics, similar to blog articles from most commercial sources.

Personally, I think the pricing model for bit is itself a bit overpriced, not that it won't suit larger organizations, but still not convinced of the paradigm.
tracker1 1595 days ago. link 1 point
I think that something exposing an async iterator would be cleaner to use.

  let count = 0;
  let queue = [];
  for await (const snapshot of createTraverser(...)) {
    count++;
    queue.push(sendEmail(snapshot.data());
    if (queue.length >= 50) {
      await promise.all(queue);
      queue = [];
    }
  }
  await promise.all(queue);
  console.log(`Processed ${count} users.`);

The items can simply implement the async iterator methods, and fetch in batches internally.
tracker1 1595 days ago. link 1 point
To the author, would suggest replacing the raw XHR requests with fetch api, to simplify the examples that imo distract from the topic at hand.
tracker1 1595 days ago. link 2 points
I'm not sure singleton is really useful for modern JS/TS.  I tend to just have a module with a declared export or set of exports for this use case.

An example is normalizing values either injected by the server or set via a request from the api or config server. As the first script.

ex: <script src="https://config-server/base.js"></script>

Then in-code, I use a module that normalizes the global variables the base.js sets. `global.__BASE__` which will include language strings, feature flags/toggles and any service urls.  I use feature/base.js from my code, that exposes the globals in a normalized patter... such as the current language and extra interfaces.

---

On observers, I tend to favor the simpler model that a node-style event emitter has.  For the DOM, you can subscribe and trigger non-standard events, though TS makes this difficult.

---

Factories are rarely needed in JS/TS, I tend to bucket them in with IoC and DI,

--- 

It's good to know the pattern, but the JS/TS platforms, language and tooling allows for simpler solutions in JS.  This is just my own opinion.
[more]