Ivan Novikov

@jitl @johnsoncodehk With `yield *` there's again a problem that you can't re-run just the part of the gen fn after `yield *`. It's useful though for cancellation and LazyPromise supports it: #generator-syntax" target="_blank" rel="nofollow noopener">github.com/lazy-promise/l…

@ivan7237d @johnsoncodehk you can do reasonable “async signal” using something like Effect.ts’s `yield *` if it’s used to resume/restore the current observer after each promise resolves. i also tried a babel plugin but it was quite slow adding a `maybeRestoreAsyncContext` around each `await`

Some notes on building alien-signals. gist.github.com/johnsoncodehk/…

A proof-of-concept async signals library built on top of LazyPromise and alien-signals: github.com/lazy-promise/l…

@johnsoncodehk I guess with AsyncContext, there's still a problem that you can't re-run the part of an async function after one of the `await`s, only the whole function. Anyway, I've formalized my intuition into this library based on alien-signals, it was super fun: github.com/lazy-promise/l…

@ivan7237d Interesting idea, but async signals' core challenge is dep tracking across async boundaries. We'll need to revisit this after TC39 AsyncContext lands.

@rtfeldman Moi

I understand that LLMs write prose the way they do "because training set," but who are these psychopaths in the training set that put spaces around their em dashes?

@RyanCarniato "I'm trying to create more library/framework authors" sure did the trick with me. Reactively was a big deal too because I couldn't make heads or tails of the actual Solid codebase

Common misconception. My content isn't to make you better at your job or show you the latest and greatest way to get things done. I'm trying to create more library/framework authors. That requires its own type of critical thinking. If you become more productive, that's a bonus.

Just published: Cancelable async tasks and typed server errors with SolidJS and LazyPromise dev.to/ivan7237d/canc…

@RyanCarniato @solid_js Might be an irrelevant question, but I’m wondering if in a hypothetical world where promises fire synchronously rather than in microtasks, there would still be a need for ‘flush’

If I had an approach to async for future @solid_js that requires no wrappers, no compiler, non-blocking render, no coloration, just works. But it requires `setSignal` (and derived values) to stay in the past until `flush` like React. Would you take it?

@mattpocockuk I wonder if there other people who like me go for DYI promises that have the familiar api of regular promises, but have typed errors and are lazy/cancelable

I'm at the "building my own type-safe error handling library" part of my eventual Rust/OCaml/Effect arc. Can't rush these things

@mattpocockuk (passing excessive props inline I mean)

@mattpocockuk The way I think of it is there are actual errors and there are lint warnings about unused code. TS does both. Example of the first is passing to some function an object w not enough props, example of the second is passing excessive props.

What, when you learned it, made TypeScript click for you?

Fully rewrote github.com/ivan7237d/1log so the api is not ugly anymore

@wesleytodd @andrestaltz @rauschma Is that because there's not enough flexibility? I personally haven't used the debug package, but built something a little bit similar (github.com/ivan7237d/1log) and wonder if it has the same pitfalls 🤔

@andrestaltz @rauschma Someday I will finally get around to finishing my doctoral thesis titled “The debug package: it’s the worst and you should instead accept a logger as an option”

1. In Node.js shell scripts, I use console.log() for output. 2. I also use it for debugging. To distinguish the two use cases, I include unique strings such as '@@@' when doing (2), so that I can find and remove later. Wondering: Switch to sth. else for either (1) or (2)?

@cryptoquick @erhannah I was thinking along the same lines: github.com/ivan7237d/1log

@erhannah const { log } = console const logger = (...args) => { log(...args) return args[0] } Example: output(logger(input(data), 'log input data'))

Released 1log 3.0 with support for logging async functions and async iterables github.com/ivan7237d/1log #javascript

@enesTufekci_ @muratcorlu @bcinarli @fkadev TS type inference does work well with pipe(), especially since TS 3.4. I guess like any other pattern, pipe() can be misused, but my experience with it was good. I actually wrote a post about it yesterday dev.to/ivan7237d/i-ve…

@muratcorlu @bcinarli @fkadev Typescript probably would slap on this code. I cant see this code typed properly.

Why do some engineers write their codes by only `pipe`s? I do not believe it is the only way for functional programming. It breaks the readability and the understandability of the code.

An article I just published. I do recommend this utility function to just about any JS/TS developer. dev.to/ivan7237d/i-ve… #JavaScript #TypeScript #functional

@floydophone I wonder if the solution is auto-advancing timers in Jest? I wrote a comment about it #issuecomment-778406733" target="_blank" rel="nofollow noopener">github.com/facebook/jest/… but take it with a grain of salt because I hadn't had much experience testing React components

even worse, these warnings can be triggered by subtle changes in your dependencies. now you've got implicit coupling between your test case and all of your recursive deps & you need to be constantly thinking about whether something is sync or not.

how are we all ok with the current state of testing in react? that the act() warning is a constant source of pain & that the solution is to sleep for a nondeterministic amount of time is a huge indictment of how we test.

1log: console.log() replacement with superpowers, for #NodeJs and the browser. Returns its argument so you can just call log() anywhere, logs Promise resolution delay, supports nested function calls, and plugins! #JS github.com/ivan7237d/1log