profile
viewpoint
Mateusz Burzyński Andarist @livechat Wrocław, Poland

Andarist/babel-plugin-annotate-pure-calls 53

This plugins helps with annotating top level functions calls with #__PURE__ comment.

aaronshaf/react-callbag-subject 8

Asynchronous pipelines in React using callbags

aaronshaf/callbag-gamepads 7

Callbag source for connected gamepad inputs

aaronshaf/callbag-animation-frames 5

Callbag listenable source sending DOMHighResTimeStamp at display refresh rate

aaronshaf/callbag-keyboard 3

Callbag source for the keyboard

Andarist/are-hook-inputs-equal 3

A comparator function for previous and current React hook inputs.

aaronshaf/callbag-flatten-iter 2

Callbag operator that flattens iterables

Andarist/babel-check-duplicated-nodes 1

🐠 Babel helper module for transforms authors to check the AST against duplicated nodes.

issue commentopencollective/opencollective

Donations as a spam vector

BUMP for stale bot

alanna

comment created time in an hour

pull request commentemotion-js/emotion

Optimize hashing for size and performance

Would you be willing to write down what has been changed, what have you tried in the process and what you have learned about engines while doing this? It would be both super interesting, helpful for reviewing this and would serve as a reference for future readers.

kripod

comment created time in 3 hours

issue commentdavidkpiano/xstate

useService and side-effects

Keep in mind that you should not use XState's state as a dependency of an effect, because you might miss stuff when React decides to batch subsequent rerenders.

A more safe version of this would look something like this: https://codesandbox.io/s/admiring-thompson-o5wbo

I still have to read carefully through @CodingDive's latest post so I can post a comment on all the mentioned concerns etc, but I would like to mention one thing now - I believe that the pattern presented by me is quite powerful and not that much of a hack (maybe besides "connecting" those 2 services in a parent-child relationship). It allows you to split the implementation, decoupling those 2 to some extent in a way that it, for example, allows you to codesplit them, whereas if you embed everything within a single machine definition (referencing other machines directly) you make codesplitting this harder.

hnordt

comment created time in 3 hours

delete branch davidkpiano/xstate

delete branch : preconstruct

delete time in 18 hours

push eventdavidkpiano/xstate

Mateusz Burzyński

commit sha 605557741e5f11e0054b9ca0b78ca86eae013f8d

Use preconstruct to build dist files (#1016)

view details

push time in 18 hours

PR merged davidkpiano/xstate

Reviewers
Use preconstruct to build dist files

This unifies the build setup for the whole monorepo - it's using a single tool with a single, minimal, config. preconstruct is opinionated about what files are being built, how they are being built, what filenames they have. Its benefits:

  • monorepo support
  • ease of adding custom entries (!)
  • constraining some things allows for autofixing, validation and similar features (which were helpful when migrating!)
  • it's built around "best practices" and will evolve with them
  • preparing dist files is easy to get wrong, because for a such "minor" thing it is super complex topic, so using a wrapper tool is the only sane thing to do in a long run

Other things:

  • switch to Babel for transpilation. preconstruct only works with it - but it also gives us more fine-grained control over the transpilation output & allows us to add custom transforms in the future. Besides added config - this is really not a big deal, changes which had to be made for this were rather minimal.
  • temporarily removed typechecking from jest - I plan to bring it back, but currently, I haven't found a perfect way to do it. I have an idea how this should work - the best thing would be to use a jest runner for this, but the existing one is super slow. I've reached to some people to see how the situation can be improved - however I don't want to stall this PR over this.
  • centralize scripts (build, test) at the root -> way less configs, but all of them kinda have to be ran from the root (a minor downside in my opinion)
+2480 -2877

2 comments

64 changed files

Andarist

pr closed time in 18 hours

PR opened davidkpiano/xstate

Reviewers
Introduce a correct test for an internal transition targeting history state

My reasoning here was almost correct, but I've missed the fact that the parent (second) of the history state was actually never exited thus the exited configuration (second.other) was never actually supposed to be saved in the historyValue.

This is somewhat a weird case - because we are already in the supposedly saveable part of the state and we are able to target the default state configuration by targeting the history state, even though we were already in that subtree (so one could think that we should already enter stored state configuration and not the default one).

I believe though that the reasoning here is OK - this is how SCXML algos deal with this situation.

+27 -60

0 comment

1 changed file

pr created time in 18 hours

Pull request review commentdavidkpiano/xstate

Machine JSON Schema definition

+---+'xstate': minor+---++The machine can now be safely JSON-serialized, using `JSON.stringify(machine)`. The shape of this serialization is defined in `machine.schema.json` and reflected in `machine.definition`.

I think you have meant that machine.defiinition can be safely serialized - as that is what you are doing in tests: https://github.com/davidkpiano/xstate/blob/55aa589648a9afbd153e8b8e74cbf2e0ebf573fb/packages/core/test/json.test.ts#L85

I would be in favor of keeping machine.definition serializable, rather than the machine itself. IMHO makes it more explicit what actually gets serialized, especially that toJSON put on a Machine would just proxy to serializing .definition

davidkpiano

comment created time in 19 hours

Pull request review commentdavidkpiano/xstate

Machine JSON Schema definition

 class StateNode<       internal,       eventType: transitionConfig.event     };++    Object.defineProperty(transition, 'toJSON', {+      value: () => ({+        ...transition,+        target: transition.target+          ? transition.target.map(t => `#${t.id}`)+          : undefined,+        source: `#{this.id}`

Could you illustrate this with an example?

davidkpiano

comment created time in 19 hours

Pull request review commentdavidkpiano/xstate

V5: History refactor

+---+'xstate': major+---++The `internal` property will no longer have effect for transitions on atomic (leaf-node) state nodes. In SCXML, `internal` only applies to complex (compound and parallel) state nodes:++> Determines whether the source state is exited in transitions whose target state is a descendant of the source state. [See 3.13 Selecting and Executing Transitions for details.](https://www.w3.org/TR/scxml/#SelectingTransitions)++```diff+// ...+green: {+  on: {+    NOTHING: {

so this only breaks reentering using internal transitions? the description put upfront is quite abstract, would be good to mention concrete scenarios when this thing matters

davidkpiano

comment created time in 20 hours

push eventdavidkpiano/xstate

David Khourshid

commit sha e9267abfb3595df57cb868241414df85ac52ff7b

Refactor history WIP

view details

David Khourshid

commit sha 44a49946c0e73e7d4738ec611fabd346e21d11bb

Remove HistoryValue

view details

David Khourshid

commit sha 04e89f90f97fe25a45b5908c45f25a513f0fd70f

Add changeset

view details

David Khourshid

commit sha b4277b898358e25788a8ae91c788d7f3308fd55c

Update graph test snapshots

view details

David Khourshid

commit sha 2a601c037d2a4f31080c99db29b5163fd57aefbc

historyMap -> historyValue

view details

David Khourshid

commit sha 7a32767a5fd041b2cf78e9dfbd9ce255c46f9308

Reword changeset

view details

David Khourshid

commit sha 268c569b83cb300a2e94c1450ef96e2147bf5b06

Add HistoryValue type

view details

David Khourshid

commit sha efe7de4e89882609e956535c98cb157d484c0386

Refactor exit set computation according to SCXML algos

view details

David Khourshid

commit sha 7aea56364979dc7e3e187a04f0024d0ee4e6ef79

Begin exitSet refactor

view details

David Khourshid

commit sha 79bdc26dedeb60d0682c1d1d94ffa817d288b904

WIP: add exitStates() function

view details

David Khourshid

commit sha 09cac2d489bd04543f402249421869d78c05247c

WIP

view details

David Khourshid

commit sha ef34d032a69a284a36aa304e3615827202988e3f

Almost all tests passing

view details

David Khourshid

commit sha 51a0c04277344efa90543c31b2c2cb46eba0b316

Working on SCXML tests - ensure that internal queue events are raised

view details

David Khourshid

commit sha 3d86216a78730897a6028e87cd8c4474588ba877

All tests pass! Now to fully refactor...

view details

David Khourshid

commit sha 078fad5eb9ac77cd3a369303a1829c7b16508b9a

Refactor WIP

view details

David Khourshid

commit sha d1690b47cb6467317c5754480c52d13629dae073

Merge branch 'next' into v5/history

view details

David Khourshid

commit sha 84cebb9f3ff07c0334f87fc6778323c206c8b079

Fix type

view details

David Khourshid

commit sha bb0d70524193de1d197357b2624a160ff4f00cff

Refactor WIP: mutConfiguration

view details

David Khourshid

commit sha 6017c5c9bbc426152fb0d251f413e7125faf65a6

Refactor to mut WIP

view details

David Khourshid

commit sha 2e6e2339189dcb18e87760736b6a1fb707c8ab1e

More mutability refactoring

view details

push time in 20 hours

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export class StateNode<       return undefined;     }     if (!nextStateNodes.length) {-      return {-        transitions: [selectedTransition],-        entrySet: [],-        exitSet: [],-        configuration: state.value ? [this] : [],-        source: state,-        actions-      };+      return [selectedTransition];     }

Good catch! Yes - this same value is returned from both of those code branches, so we should be able to just return it without introducing a conditional path.

davidkpiano

comment created time in a day

pull request commentdavidkpiano/xstate

Fix wrong import in README

Thanks!

stefanoeb

comment created time in a day

push eventdavidkpiano/xstate

Stefano Bourscheid

commit sha 99b6d9a2244fccbd63b9be089d4e2dec5b75bf62

Fix wrong import in @xstate/graph README (#1017)

view details

push time in a day

PR merged davidkpiano/xstate

Reviewers
Fix wrong import in README
+2 -2

2 comments

1 changed file

stefanoeb

pr closed time in a day

Pull request review commentdavidkpiano/xstate

Machine JSON Schema definition

+{+  "type": "object",+  "$schema": "http://json-schema.org/draft-07/schema",+  "definitions": {+    "actionObject": {+      "type": "object",+      "properties": {+        "type": { "type": "string" },+        "exec": {+          "oneOf": [+            { "type": "string" },+            { "$ref": "#/definitions/functionObject" }+          ]+        }+      },+      "required": ["type"]+    },+    "baseStateNode": {+      "type": "object",+      "properties": {+        "id": {+          "type": "string"+        },+        "key": {+          "type": "string"+        },+        "type": {+          "type": "string",+          "enum": ["atomic", "compound", "parallel", "final", "history"]+        },+        "order": {+          "$ref": "#/definitions/order"+        }+      },+      "required": ["id", "key", "type"]+    },+    "compoundStateNode": {+      "allOf": [+        { "$ref": "#/definitions/baseStateNode" },+        {+          "type": "object",+          "properties": {+            "type": {+              "type": "string",+              "pattern": "compound"+            },+            "entry": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "exit": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "initial": {+              "type": "string"+            },+            "invoke": {+              "$ref": "#/definitions/invokeArray"+            },+            "on": {+              "$ref": "#/definitions/transitionsObject"+            },+            "states": {+              "$ref": "#/definitions/statesObject"+            }+          },+          "required": ["states"]+        }+      ]+    },+    "parallelStateNode": {+      "allOf": [+        { "$ref": "#/definitions/baseStateNode" },+        {+          "type": "object",+          "properties": {+            "type": {+              "type": "string",+              "pattern": "parallel"+            },+            "entry": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "exit": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "invoke": {+              "$ref": "#/definitions/invokeArray"+            },+            "on": {+              "$ref": "#/definitions/transitionsObject"+            },+            "states": {+              "$ref": "#/definitions/statesObject"+            }+          },+          "required": ["states"]+        }+      ]+    },+    "atomicStateNode": {+      "allOf": [+        { "$ref": "#/definitions/baseStateNode" },+        {+          "type": "object",+          "properties": {+            "type": {+              "type": "string",+              "pattern": "atomic"+            },+            "entry": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "exit": {+              "type": "array",+              "items": {+                "$ref": "#/definitions/actionObject"+              }+            },+            "invoke": {+              "$ref": "#/definitions/invokeArray"+            },+            "on": {+              "$ref": "#/definitions/transitionsObject"+            }+          },+          "required": ["on"]+        }+      ]+    },+    "historyStateNode": {+      "allOf": [+        { "$ref": "#/definitions/baseStateNode" },+        {+          "type": "object",+          "properties": {+            "type": {+              "type": "string",+              "pattern": "history"+            },+            "history": {+              "type": "string",+              "enum": ["shallow", "deep"]+            }+          },+          "required": ["history"]+        }+      ]+    },+    "finalStateNode": {+      "allOf": [+        { "$ref": "#/definitions/baseStateNode" },+        {+          "type": "object",+          "properties": {+            "type": {+              "type": "string",+              "pattern": "final"+            },+            "data": {+              "type": "object"+            }+          }+        }+      ]+    },+    "statesObject": {+      "type": "object",+      "patternProperties": {+        "^.*$": {+          "oneOf": [+            { "$ref": "#/definitions/atomicStateNode" },+            { "$ref": "#/definitions/compoundStateNode" },+            { "$ref": "#/definitions/parallelStateNode" },+            { "$ref": "#/definitions/historyStateNode" },+            { "$ref": "#/definitions/finalStateNode" }+          ]+        }+      }+    },+    "transitionsObject": {+      "type": "object",+      "patternProperties": {+        "^.*$": {+          "type": "array",+          "items": {+            "type": "object",+            "properties": {+              "actions": {+                "type": "array",+                "items": {+                  "$ref": "#/definitions/actionObject"+                }+              },+              "cond": {+                "type": "object"+              },+              "eventType": {+                "type": "string"+              },+              "source": {+                "type": "string"+              },+              "target": {+                "type": "array",+                "items": {+                  "type": "string"+                }+              }+            },+            "required": ["actions", "eventType", "source", "target"]+          }+        }+      }+    },+    "invokeObject": {+      "type": "object",+      "properties": {+        "type": {+          "type": "string"+        },+        "id": {+          "type": "string"+        },+        "src": {+          "type": "string"+        },+        "autoForward": {+          "type": "boolean",+          "default": false+        }+      },+      "required": ["type", "id", "src"],+      "additionalProperties": false

I'm not sure - but maybe you test the wrong thing? onError & onDone are part of the config but they are converted to transitions internally and thus probably available on the definition (and not the config)

davidkpiano

comment created time in a day

pull request commentdavidkpiano/xstate

V5: History refactor

Oh - I forgot, it would be great to describe in short every user-facing changes in changesets.

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 const testGroups = {     'history1',     'history2',     'history3',-    // 'history4', // TODO: support history nodes on parallel states+    'history4', // TODO: support history nodes on parallel states

this got uncommented, but has a TODO comment now, is this test passing now? if yes - why there is a TODO besides it?

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export function getChildren<TC, TE extends EventObject>(   return keys(stateNode.states).map(key => stateNode.states[key]); } +export function getProperAncestors<TContext, TEvent extends EventObject>(+  stateNode: StateNode<TContext, any, TEvent>,+  toStateNode: StateNode<TContext, any, TEvent> | null+): Array<typeof stateNode> {+  const ancestors = new Set<typeof stateNode>();

this is a fresh Set, since we only add ancestors recursively to it there is no chance for duplicates being added into that, so instead of creating a Set upfront and casting it to an Array at the end we should be able to just create an Array and push to it

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export interface StateConfig<TContext, TEvent extends EventObject> {   context: TContext;   _event: SCXML.Event<TEvent>;   _sessionid: string | null;-  historyValue?: HistoryValue | undefined;

isnt this important for rehydration? shouldnt we accept it?

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export class StateNode<   public next(     state: State<TContext, TEvent>,     _event: SCXML.Event<TEvent>-  ): StateTransition<TContext, TEvent> | undefined {+  ): Transitions<TContext, TEvent> | undefined {+    if (this.type === 'history' && state.historyValue[this.id]) {

this is a little bit confusing to me - why do we have to have this check here? If we have stored historyValue for a particular id then we should enter those states, not return an empty array.

Seems like this is handled upstream in the resolveHistory already and this condition can be removed, or do I miss something?

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export class StateNode<    protected __cache = {     events: undefined as Array<TEvent['type']> | undefined,-    relativeValue: new Map() as Map<StateNode<TContext>, StateValue>,+    relativeValue: new Map() as Map<

I've searched through the codebase and this seems to stay unused, some artifact of the past probably.

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

 export class State<      Object.defineProperty(this, 'nextEvents', {       get: () => {-        return nextEvents(config.configuration);+        return nextEvents([...new Set(config.configuration)]);

is this needed? shouldnt we assume valid input (no duplicates)?

davidkpiano

comment created time in a day

Pull request review commentdavidkpiano/xstate

V5: History refactor

+---+'xstate': major+---++The history resolution algorithm has been refactored to closely match the SCXML algorithm, which changes the shape of `state.historyValue`to map history state node IDs to their most recently resolved target state nodes.
The history resolution algorithm has been refactored to closely match the SCXML algorithm, which changes the shape of `state.historyValue` to map history state node IDs to their most recently resolved target state nodes.
davidkpiano

comment created time in a day

issue commentdavidkpiano/xstate

Compilation issues with Typescript v3.8.2 & xstate v4.6.7

This is not a repro case though - to investigate we need to have a runnable, complete, repro case

Khaled-Ch

comment created time in a day

Pull request review commentdavidkpiano/xstate

Use preconstruct to build dist files

     "url": "https://github.com/davidkpiano/xstate/issues"   },   "homepage": "https://github.com/davidkpiano/xstate/tree/master/packages/core#readme",+  "dependencies": {

Nope, it's currently part of the core package and has to declared as either dependency or peer dependency.

It's because @xstate/scxml imports toMachine here: https://github.com/davidkpiano/xstate/blob/53bed804ec90e9c2821ed5dcd9d1b9443b8ae533/packages/xstate-scxml/test/scxml.test.ts#L7 which is depending on this xml-js package.

This is not a big deal though - we only need to restructure things a little bit. Most likely core/src/scxml.ts should just be moved to @xstate/scxml package and then we could remove this dependency from here (because it would be moved to the other package). This should in a followup PR - if you have any other idea on how to restructure those things then let's discuss this on Slack.

Andarist

comment created time in a day

Pull request review commentdavidkpiano/xstate

Use preconstruct to build dist files

     "url": "https://github.com/davidkpiano/xstate/issues"   },   "homepage": "https://github.com/davidkpiano/xstate/tree/master/packages/core#readme",+  "dependencies": {

This had to be included because xstate imports it from within src/scxml.ts. I bet you don't want to have this here - but we'd have to restructure things in some followup PR to get rid of this.

This actually has showcased a really nice validation provided by preconstruct - it has validated, during build, if your package.json declares all imported dependencies.

Andarist

comment created time in 2 days

Pull request review commentdavidkpiano/xstate

Use preconstruct to build dist files

   "name": "xstate",   "version": "4.7.8",   "description": "Finite State Machines and Statecharts for the Modern Web.",-  "main": "lib/index.js",-  "module": "es/index.js",-  "types": "lib/index.d.ts",

you might be wondering why "types" have been removed here and in other packages - typings are distributed in dist directory and main entry point receives a sibling .d.ts file which allows TS to resolve distributed types, making "types" field obsolete

Andarist

comment created time in 2 days

Pull request review commentdavidkpiano/xstate

Use preconstruct to build dist files

+const { NODE_ENV } = process.env;+const isTest = NODE_ENV === 'test';++module.exports = {+  presets: [+    [+      '@babel/preset-env',

in followup PRs I'm going to optimize this Babel config to output terser code

Andarist

comment created time in 2 days

Pull request review commentdavidkpiano/xstate

Use preconstruct to build dist files

 export { export type Actor = ActorType;  export * from './types';++// TODO: decide from where those should be exported

Those had to be exposed because they were used by other packages. By switching to preconstruct we are effectively hiding all internal modules from the outside world, so those couldn't be accessed anymore by reaching into xstate/lib.

Andarist

comment created time in 2 days

PR opened davidkpiano/xstate

Use preconstruct to build dist files

This unifies the build setup for the whole monorepo - it's using a single tool with a single, minimal, config. preconstruct is opinionated about what files are being built, how they are being built, what filenames they have. Its benefits:

  • monorepo support
  • ease of adding custom entries (!)
  • constraining some things allows for autofixing, validation and similar features (which were helpful when migrating!)
  • it's built around "best practices" and will evolve with them
  • preparing dist files is easy to get wrong, because for a such "minor" thing it is super complex topic, so using a wrapper tool is the only sane thing to do in a long run

Other things:

  • switch to Babel for transpilation. preconstruct only works with it - but it also gives us more fine-grained control over the transpilation output & allows us to add custom transforms in the future. Besides added config - this is really not a big deal, changes which had to be made for this were rather minimal.
  • temporarily removed typechecking from jest - I plan to bring it back, but currently, I haven't found a perfect way to do it. I have an idea how this should work - the best thing would be to use a jest runner for this, but the existing one is super slow. I've reached to some people to see how the situation can be improved - however I don't want to stall this PR over this.
  • centralize scripts (build, test) at the root -> way less configs, but all of them kinda have to be ran from the root (a minor downside in my opinion)
+2487 -2881

0 comment

64 changed files

pr created time in 2 days

push eventdavidkpiano/xstate

Mateusz Burzyński

commit sha 53bed804ec90e9c2821ed5dcd9d1b9443b8ae533

Use preconstruct to build dist files

view details

push time in 2 days

create barnchdavidkpiano/xstate

branch : preconstruct

created branch time in 2 days

issue commentemotion-js/emotion

emotion-theming@11.0.0-next.6 package missing source/types

emotion-theming got moved into @emotion/react, so it "no longer exists" - the published version is deprecated.

You can just import useTheme, ThemeProvider and withTheme from the @emotion/react itself.

tpict

comment created time in 2 days

issue commentgr2m/universal-user-agent

"module" being browser-specific breaks bundling with Parcel for node

I still believe the issue stands on its own but definitely this try/catch is helpful 👍

Andarist

comment created time in 2 days

fork Andarist/jest-runner-tsc

🃏A Jest runner for the TypeScript compiler

fork in 2 days

Pull request review commentemotion-js/emotion

Optimize hashing for size and performance

 // @flow /* eslint-disable */-// murmurhash2 via https://github.com/garycourt/murmurhash-js/blob/master/murmurhash2_gc.js+// Inspired by https://github.com/levitation/murmurhash-js+// Ported from https://github.com/aappleby/smhasher/blob/61a0530f28277f2e850bfc39600ce61d02b518de/src/MurmurHash2.cpp#L37-L86 -export default function murmurhash2_32_gc(str: string) {-  var l = str.length,-    h = l ^ l,-    i = 0,-    k+export default function murmur2(str: string) {+  // 'm' and 'r' are mixing constants generated offline.+  // They're not really 'magic', they just happen to work well. -  while (l >= 4) {+  // const m = 0x5bd1e995;+  // const r = 24;++  // Initialize the hash to a 'random' value++  var len = str.length,+    h = len ^ len;

This is always equal to 0 (len ^ len === 0). Can we just use 0 here? "Initialize the hash to a 'random' value" seems to be incorrect here - original algo initializes this using a received seed value (making it random~), but we dont have this here.

kripod

comment created time in 2 days

pull request commentemotion-js/emotion

Optimize hashing for size and performance

I've asked a friend about this and he has suggested to just perform 32bit operations, avoiding those 16bit conversions. I've prepared a small benchmark to test this out and it seems to work great for the Math.imul alone.

Could you try this out in this PR?

kripod

comment created time in 2 days

issue closedredux-saga/redux-saga

What is a proper way to close an eventChannel

Hi, are there any approaches how to destroy eventChannel, that should exist all the time that application is live & there's no particular event to fire close() method on a channel. Is it ok just to provide an unsubscribe function as a return value? Will this function be ever fired then on any internal event like destroying parent saga or something else? I don't see that this function is ever called rather than when I manually call purchaseChannel.close(). My concern is that each time parent saga is run, it could potentially add new event listener without removing previous ones.

const purchaseChannel = eventChannel(emit => {
  const listener = (purchase: Purchase) => {
    emit(purchase)
  }
  const purchaseListener = eventEmitterInstance(listener) // event emitter with a subscribed listener
  return (): void => {
    purchaseListener.remove()
  }
})

closed time in 2 days

meteorra

issue commentredux-saga/redux-saga

What is a proper way to close an eventChannel

Not quite, but in general - yes you can extract your handler and use takeEvery with it.

The difference is that takeEvery creates a task descriptor and returns it synchronously to the caller, so your saga will continue its execution and will jump to this finally block immediately.

You need to "block" the saga, so the finally block can only be executed when saga runtime decides to cancel this whole subtree of sagas or an uncaught error gets thrown. You can, for example, abuse join effect to do this, because takeEvery's internal saga never returns:

function *saga(){
 const chan = eventChannel(() => {/* */})
 try {
   const task = yield takeEvery(chan, chanListener)
   yield join(task)
 } finally {
   chan.close()
 }
}

Algternatively you can create a more explicit helper for this:

const blocker = () => new Promise(() => {})
const block = () => call(blocker)

which you could use like this:

yield block()
meteorra

comment created time in 2 days

issue commentemotion-js/emotion

Css classes are not splitted to treat output CSS effectively

Sub and SubInRed are treated as completely separate components - each has its own unique class name and thus they SubInRed won't be targeted by Title's styles.

Technically we maybe could change this behavior, but I'm not convinced that we should. You could raise a separate issue about this so we could discuss this - we are working on v11 so this potentially could make it into that release, although keep in mind that we probably won't decide to support this.

adambisek

comment created time in 2 days

pull request commentemotion-js/emotion

Optimize hashing for size and performance

As the regression~ happens in v8 we can just use node to check this, you can use node --print-code script.js to see the generated bytecode.

This is of course rather hard to analyze if you don't have a good knowledge of assembly code. Mine is definitely rusty and I wouldn't be able to analyze this quickly myself.

Some starting materials https://medium.com/dailyjs/understanding-v8s-bytecode-317d46c94775

Let me know if you are capable of jumping into this, if not - let's wait to see if Mathias answers.

kripod

comment created time in 2 days

pull request commentemotion-js/emotion

Optimize hashing for size and performance

Not sure if you have expertise in that area but maybe you could compare generated assembly code for both versions?

kripod

comment created time in 2 days

issue commentredux-saga/redux-saga

What is a proper way to close an eventChannel

You need to manually close it because eventChannel is not yielded to the saga runtime, so it has no means to close it automatically as it's not even aware of its existence.

function *saga(){
  const chan = eventChannel(() => {/* */})
  try {
    while (true) {
      const ev = yield take(chan)
      /* do smth with ev */
    }
  } finally {
    chan.close()
  }
}
meteorra

comment created time in 2 days

pull request commentemotion-js/emotion

Optimize hashing for size and performance

This looks awesome! ❤️

Could you also prepare a perf comparison of the previous version of this hash function and the proposed one? Would be great to also measure the overall gains, rather than focusing solely on the Math.imul perf.

kripod

comment created time in 2 days

issue commentemotion-js/emotion

Css classes are not splitted to treat output CSS effectively

What's the issue that you are seeing? That you see the same class names being duplicated? This is most likely due to hot-reloading and emotion losing the state what it has already injected to the document, but the document itself being reused.

adambisek

comment created time in 2 days

pull request commentfacebook/react

Provide esm entry point for react-is

Im super glad to hear that! @TrySound will you want to continue work on this one?

TrySound

comment created time in 2 days

issue openedazz/jest-runner-tsc

How can I help to get this faster?

I'm really interested in seeing the speed of this runner improve - would you be willing to share with me what you have tried in the past? Is there an interest in improving this?

From what I understand a new compiler is being created per test file right now, so probably the best improvement would be trying to reuse a single compiler instance and using TS's incremental API - I think is the strategy used by Fork TS Checker Webpack Plugin which I found to be pretty fast. Not 100% sure how this would play out with jest worker farm and how this is even utilized here, but this is something that could be explored.

created time in 3 days

startedazz/jest-runner-tsc

started time in 3 days

issue commentdavidkpiano/xstate

ESM loading fails for native Node.js@13.x.x loader

I've educated myself about ESM support in node@13 and I think I understand its intricacies now. It's not as easy to support it as I have thought - when you also want to support older nodes, bundlers etc (and we do).

I will explore making it work in v5, but at the moment I don't think it's worth it to include this in v4.

If you want to patch your node_modules and xstate in it then I think this should work if you add this to pkg.json

"type": "module",
"exports": "./es/index.js"
hbarcelos

comment created time in 3 days

pull request commentdavidkpiano/xstate

Use pretty-quick instead of lint-staged

Yes, but is it used for other tasks in practice? I haven't seen such a case so far :)

It's pretty often also used for linting. I also had to generate .md files couple of times as part of the precommit hook.

You can have both tools alongside anyway if there would be such need in the future.

Right, but they are similar enough that's probably not worth to keep both and coordinate their usage.

FredyC

comment created time in 3 days

issue commentAndarist/lerna-alias

Update README with real examples

A real-world example can be found here: https://github.com/davidkpiano/xstate/blob/19b0a22d8cb0023e2bdf7830169d1594f96e63f3/packages/xstate-react/jest.config.js#L5

I make this package to resolve its dependencies from the monorepo to resolve to respective src directories

vileen

comment created time in 3 days

issue commentramda/ramda

Problem with ECMAScript modules import in nodejs and browser

I havent played much with them yet - but the answer is to provide conditional exports in package.json. Its a great opportunity for me to learn more about how to setup this correctly - so give me a couple of days and ill be back with a PR for this

NtsDK

comment created time in 3 days

issue commentredux-saga/redux-saga

Add additional benifit to readme

I think this would have to go in pair with an example. Could you provide one? But basically yes - saga can express promise-based flows fine with additional benefits such as cancellation support and more.

brantphoto

comment created time in 4 days

issue commentemotion-js/emotion

Kebab keys for object styles

CSS itself is kebab-case - yes, but CSS represented in JS - not so much. CSSStyleDeclaration API has camelCased properties - this the one which you get if you for example check .style property of any node.

steida

comment created time in 4 days

issue commentatlassian/changesets

Change changelog filepath/name

Probably this would only require checking if changelog.md exists here (case-insensitive match): https://github.com/atlassian/changesets/blob/0e8d10c101b71ac616d491180c3d338280d1576b/packages/apply-release-plan/src/index.ts#L102

and reuse what has been found

Siilwyn

comment created time in 4 days

PR opened davidkpiano/xstate

Reviewers
Small cleanup of build-related stuff in xstate-viz

This still doesnt really build correctly (there are runtime errors), but at least parcel can actually build this example now.

+1 -14

0 comment

2 changed files

pr created time in 4 days

create barnchdavidkpiano/xstate

branch : cleanup-xstate-viz-tooling

created branch time in 4 days

issue commentemotion-js/emotion

Kebab keys for object styles

We dont want to implement too many features in this library - camelCase match browser APIs, other css-in-js implementations and has good strict coverage in TS types provided by csstype package

steida

comment created time in 4 days

pull request commentdavidkpiano/xstate

Use pretty-quick instead of lint-staged

Thanks for the PR!

I'm not the biggest fan of this change though - I don't see anything, in particular, lacking from the lint-staged and I haven't noticed it being too slow. It gets the job done.

pretty-quick also seems focused on running prettier, while lint-staged is a more general tool and can be used for other tasks as well.

FredyC

comment created time in 4 days

issue commentemotion-js/emotion

RFC: Replace array value fallbacks with array value concatenation

The last defined property with the same key wins, doesnt it? 😉

tkh44

comment created time in 4 days

push eventlivechat/angular-livechat

Mateusz Burzyński

commit sha c6a5d129ef011aefbe3a608dfed72412cc89752f

Cleanup build setup

view details

push time in 4 days

issue commentemotion-js/emotion

Using Gatsby and components as selectors

Its hard to give a better one because interpolating a function (and your component is a function) is a valid use case. But sure - if you have any idea on how this could be improved, let me know.

falconmick

comment created time in 4 days

Pull request review commentpreconstruct/preconstruct

Allow to build projects including usage of eval

 export let getRollupConfig = (       }       switch (warning.code) {         case "EMPTY_BUNDLE":+        case "EVAL":

we could surface this as a warning, but I dont think this is really that much needed - usage of eval is so much discouraged in the community that it's quite obvious that you shouldnt use it (when not really really needed), without extra warnings/errors

Andarist

comment created time in 4 days

create barnchAndarist/preconstruct

branch : allow-eval

created branch time in 4 days

issue commentemotion-js/emotion

Styled Components Using Props Exhibit Incorrect Styles (@emotion/styled)

The problem is that you are missing a semicolon after your interpolated width and for some reason, this breaks our parser (stylis) in this context.

I'm afraid that we won't be fixing this right now because current stylis code is quite complex. It's also being reworked right now (so it should become much more maintainable) and we hope to include its rewrite in the upcoming v11. Keep in mind that it's always better to use explicit semicolons in your styles.

XxX-MLGNoob-XxX

comment created time in 4 days

pull request commentrollup/rollup

Rollup v2.0.0

q: wasnt "es" format supposed to be renamed to "esm"? or you have decided not to proceed with this one?

lukastaegert

comment created time in 4 days

issue commentemotion-js/emotion

Using Gatsby and components as selectors

Well, this happens because your second component - GalleryImage - is not a styled component. You can't target arbitrary components as selectors, only the ones created with styled

falconmick

comment created time in 4 days

pull request commentdevelopit/unfetch

Proper TS types

Yes - thats my understanding. Isomorphic-fetch wont even know about those typings here because they are not referenced anyhow from there

Andarist

comment created time in 4 days

issue commentemotion-js/emotion

Apply element style to children when hovering over parent element

At first glance, it looks OK.

arhoy

comment created time in 5 days

issue commentemotion-js/emotion

Using Gatsby and components as selectors

You have changed your code since the report. Please provide clear instructions on how to run repro case in a reliable manner in the future.

I've just added:

  ${PortraitGroup} {
    flex: 1;
  }

to your GalleryWrapper and I can't repro your issue. This component is correctly targeted in css: Screenshot 2020-02-18 at 23 34 12

falconmick

comment created time in 5 days

issue commentemotion-js/emotion

Component selectors can only be used in conjunction

https://emotion.sh/docs/globals

<Global
  styles={"@import url('https://fonts.googleapis.com/css?family=Roboto&display=swap');"}
/>
sptGabriel

comment created time in 5 days

pull request commentdevelopit/unfetch

Proper TS types

This looks good to me, but I wonder if it'll cause folks trouble because the types are now different for unfetch VS isomorphic-unfetch?

Well, depends on how you look at it. It won't cause people much trouble because one is probably not using both in the same project, but I don't know how to properly support types from this PR when using isomorphic-unfetch. I'm not aware of any way to make TS resolve types based on target environment or anything like that - it always resolves node_modules to "main".

So landing this would definitely make both of those packages providing different typings, but at least for browser-only unfetch users they would be correct and would save users from using it like a regular, full-blown fetch.

Andarist

comment created time in 5 days

issue commentemotion-js/emotion

Component selectors can only be used in conjunction

This codesandbox is using Create React App template and you can't customize babel plugins with that. This is, by design, not allowed when using CRA.

However they support Babel macros and we provide one, so if you make this change:

-import styled from "@emotion/styled";
+import styled from "@emotion/styled/macro";

This starts to work as expected.

sptGabriel

comment created time in 5 days

issue commentemotion-js/emotion

Apply element style to children when hovering over parent element

Please share a runnable repro case. We can't quite tell why this is not working just from the code snippet you have provided.

arhoy

comment created time in 5 days

issue commentmweststrate/import-size

Include 0-import cost

I've done preliminary investigation and it seems that's the fault of used import-size package. It "transforms" import "${library}"; input to import * as tmp from "${library}";console.log(tmp);. Making it effectively the same as import * as "${library}"; input.

This happens here: https://github.com/wix/import-cost/blob/a8b24cce7ef4bc7836d28a2913d3788eabc56cda/packages/import-cost/src/babelParser.js#L112

So to make what I've requested to work we should reach out to them to see if they would like to support calculating costs for bare imports, probably behind a flag or something.

Andarist

comment created time in 5 days

issue commentemotion-js/emotion

TypeScript error when component renders a styled component

Try this:

const Button: React.FC<ButtonProps> = (props) => <ButtonStyled {...props} />

criles25

comment created time in 5 days

issue commentemotion-js/emotion

Component selectors can only be used in conjunction

Please share a runnable repro case for your problem, we cant help you without such.

sptGabriel

comment created time in 5 days

delete branch livechat/livechat-public-docs

delete branch : dps-1583

delete time in 5 days

pull request commentemotion-js/emotion

Add `addReactImportForFragment` option to handle fragment shorthand

Thanks for PR - I hope to get to reviewing it in the following days, but I'm really busy lately and don't have much free time for this right now. So please wait patiently and thanks for the understanding 🙏

SidneyNemzer

comment created time in 5 days

issue commentpreconstruct/preconstruct

Additional entries don't have "types" generated

Ok, seems like .d.ts is actually generated - but because of the issue mentioned here I was thinking that I was looking at another directory (the root entry).

I feel however that maybe it should be validated that "types" got used and throw an error on that (in favor of those type files that are auto-generated). This should ofc happen only for TS projects - adding "types" manually should be supported for packages shipping .d.ts without them actually being written in TS.

Andarist

comment created time in 6 days

issue openedpreconstruct/preconstruct

Additional entries don't have "types" generated

It's not automatically generated, but even if manually added then it's not validated and cannot be fixed with preconstruct fix.

created time in 6 days

issue commentpreconstruct/preconstruct

Consider including scope name in the generated filenames

Related issue, that I think it would be great to fix together with this, is that currently additional entries don't have their entry names in the filename, which more often than not is something that wasnt expected:

An example of this can be found here: https://github.com/emotion-js/emotion/blob/4aacba54cdc65ac50bec57d8211a62fe65b6b1f7/packages/styled/base/package.json

Andarist

comment created time in 6 days

Pull request review commentpreconstruct/preconstruct

Fixed issue with temporarily created files not being cleaned up

 import { promptConfirm } from "./prompt"; import { validateIncludedFiles } from "./validate-included-files"; import { FatalError } from "./errors"; +const allSettled = (promises: Promise<any>[]) =>

based on https://tc39.es/proposal-promise-allSettled/#sec-promise.allsettled

Andarist

comment created time in 6 days

PR opened preconstruct/preconstruct

Fixed issue with temporarily created files not being cleaned up

This could not get executed in full: https://github.com/preconstruct/preconstruct/blob/d8dce6f0a3a9e144c14f6f0ff8c01bef18406fe0/packages/cli/src/validate-included-files.ts#L62-L70 because first thrown error was thrown up to the root-catch-handler and caused: https://github.com/preconstruct/preconstruct/blob/1e37a5de036ca4f897c990457676c33a6ae287bc/packages/cli/src/cli.ts#L104

This, in turn, has terminated the program - in the middle of the cleanup.

+24 -1

0 comment

2 changed files

pr created time in 6 days

create barnchAndarist/preconstruct

branch : fix/validation-cleanup

created branch time in 6 days

pull request commentmrdoob/three.js

Build: switch to a custom class transform using Babel

Are there any action points regarding the discussion here? Is there anything i can do to help migrating to es classes? I would love to improve tree-shakeability of three and having those “manual” prototypes manipulation here is the biggest deopt for that

Andarist

comment created time in 6 days

issue commentemotion-js/emotion

Using Gatsby and components as selectors

Everything should be supported. Could you share a sample repository with the issue reproduced?

falconmick

comment created time in 6 days

Pull request review commentdavidkpiano/xstate

Machine JSON Schema definition

 class StateNode<       internal,       eventType: transitionConfig.event     };++    Object.defineProperty(transition, 'toJSON', {+      value: () => ({+        ...transition,+        target: transition.target+          ? transition.target.map(t => `#${t.id}`)+          : undefined,+        source: `#{this.id}`

isn't this redundant? It shouldn't be needed for rehydration as this always points to the node on which transitions are defined and this cannot be changed or manipulated anyhow.

davidkpiano

comment created time in 6 days

Pull request review commentdavidkpiano/xstate

Machine JSON Schema definition

+import { StateNode, ActionObject, Guard, InvokeDefinition } from './';

Right, this is IMHO OK - this is orthogonal to JSON.stringify though. Do you suspect having to call smth like stringify(machineConfig) over JSON.stringify would deteriorate DX that much? Stringifying seems like a use case for rather advanced users and as such, I wouldn't expect it to be a problem.

I know this is somewhat in opposite to what I have raised previously about not having the parity between serialize & deserialize (where JSON.parse serves as deserializing algorithm here), but I wasn't sure how exactly you have envisioned this to be used.

I still think it, in general sense, would be great to have the parity between those 2. So maybe instead of adding custom toJSON to some internal structure, we should think of how to just represent the whole definition in a serializable way. We can split the serializable definition from the other data about the transition that we need at runtime (or maybe we wouldn't need splitting it - just a different representation).

If you don't want to introduce a separate stringifier then this is OK to be merged. We can try to pursue different definition representation in other PRs.

Also - Object.defineProperty is not the fastest thing in the world. Or at least it hasn't been in the past: https://humanwhocodes.com/blog/2015/11/performance-implication-object-defineproperty/ . Browsers perf characteristics are a moving target and it would have to be checked if this is still the case, but if this is uncertain - it's better to avoid it altogether (if possible ofc).

davidkpiano

comment created time in 6 days

issue commentemotion-js/emotion

@emotion/primitives and form inputs, is there a prop for html element name

So in the future, we might extend supported primitives with TextInput, once they add it 😉

marcelmokos

comment created time in 6 days

issue commentdavidkpiano/xstate

useService and side-effects

Like the todosMachine defining an action & event to focus the input when it'd be much better suited inside the todoMachine or even todoInputMachine (if it existed).

This kinda baffles me - maybe I don't understand the whole context that you have in mind.

On the one hand - you want to have this managed inside todosMachine, but on the other hand you want to only have it partially. Which exact parts would you like to have at which place? Seems like you want to have events and actions higher in the tree (parent/grandparent component) but you want to have an action's implementation closer to a consuming component. And this is mostly dictated by the fact that only there you have access to the underlying ref which you need to focus. Is that right?

Imagine implementation without considering React and how you structure its components etc. Would you do the same then? Would you try to decouple this implementation from the place where you have all the other pieces defined? I think that I wouldn't - this only introduces some indirection which in this instance, I feel, should be avoided.

You are having those machines coupled to each other anyway because their concerns are highly connected - the one higher in the tree serves as a manager/supervisor to the inner ones (among other things). From what I understand - it has the knowledge about when this particular action should happen and it "just" needs it to execute.

It seems like what you have mentioned - creating todoInputMachine - is the real answer here. If you implement it then you will be able to just send a directed command to it (FOCUS_INPUT) and have it react (😉) to it.

The main challenge though is still remaining with such - there is currently no clear answer how to have this todoInputMachine defined together with <TodoInput/> component and yet make the supervising machine aware of it (so it can send an event back to it).

There is a hidden gem that can solve this for you super nicely - you can actually pass parent as an option to the Interpreter and because useMachine starts an interpreter under the hood it forwards all of the received options to it. Check this demo out: https://codesandbox.io/s/wonderful-clarke-8q1y4

That being said - I'm not 100% convinced (I have just literally figured out this solution right now) if we should overload parent like this, or to rephrase - if we should use sendParent for this. It's super convenient though. The alternative that is also supported is that you can just grab parent's sessionId and send to it with send(event, { to: ctx => ctx.parentRef }). The main different between those 2 approaches is that the latter one doesn't establish parent-child relationship between those machines, it just allow for 2 separate machines to communicate with each other.

@davidkpiano - WDYT? I think it would be great to include one of those in the docs. This unlocks some really nice patterns, the only question is - which one should be preferred? I'll give this more thought today as well.

<img src="https://media.giphy.com/media/l0IylOPCNkiqOgMyA/giphy.gif"/>

hnordt

comment created time in 6 days

issue commentemotion-js/emotion

@emotion/primitives and form inputs, is there a prop for html element name

I actually have no experience with react-primitives and I have no idea how you should implement an input using it. It's really more of a react-primitives question rather than emotion one.

marcelmokos

comment created time in 6 days

Pull request review commentagiledigital/typed-redux-saga

Add a babel macro and mark the module as side-effects free.

+import { addNamed } from "@babel/helper-module-imports";+import { createMacro } from "babel-plugin-macros";++function typedReduxSagaMacro({ references, babel, state }) {+  const program = state.file.path;++  for (const refName of Object.keys(references)) {+    const identifierNode = addNamed(program, refName, "redux-saga/effects", {+      nameHint: refName,+    });++    for (const refPath of references[refName]) {+      refPath.node.name = identifierNode.name;++      const parentPath = refPath.parentPath.parentPath;+      if (+        parentPath.isYieldExpression() &&+        parentPath.node.delegate === true+      ) {+        parentPath.replaceWith(+          babel.types.yieldExpression(parentPath.get("argument").node),+        );+      }+    }+  }+}++export default createMacro(typedReduxSagaMacro);

you can use { keepImports: true } option and only change the source value of the import path in your macro

gilbsgilbs

comment created time in 6 days

issue commentredux-saga/redux-saga

Best way to handle your rootSaga

This is just a matter of organizing the code, doesn't matter much - I would only suggest using effects over directly yielding iterators and avoid the unnecessary nesting.

// fooSaga.js
import {takeLatest} from 'redux-saga/effects';

function* foo() { /* code logic here */}

export default function* watchFork() {
  yield takeLatest('FOO_SAGA, foo);
}

// sagas.js
import {all, fork} from 'redux-saga/effects';
import fooSaga from './fooSaga';

export function* rootSaga() {
  yield all([ fork(fooSaga) ]);
}
llauderesv

comment created time in 6 days

issue commentdavidkpiano/xstate

useService and side-effects

Hoisting all of the actions that I need to pass from react land to the very top of my actor hierarchy, where I can actually call useMachine, is an option but it would complicate the communication quite a bit.

Well - if you made particular responsibility a part of a particular machine then I would say that it's much better to colocate this stuff with it. It's basically a similar problem (& solution) to React's lifting state up

hnordt

comment created time in 6 days

pull request commentdavidkpiano/xstate

Use Set#clear() when stopping an interpreter

Thanks!

sukima

comment created time in 6 days

push eventdavidkpiano/xstate

Devin Weaver

commit sha 19b0a22d8cb0023e2bdf7830169d1594f96e63f3

Use Set#clear() when stopping an interpreter (#1008) Previously the `stop()` method would loop through the transition listeners and delete each one from the Set. This change simplifies that to using the [Set#clear()][1] method. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/clear

view details

push time in 6 days

more