profile
viewpoint
Vladimir Kurchatkin vkurchatkin Moscow

vkurchatkin/koa-connect 139

Use connect and express middleware in koa

vkurchatkin/function-origin 50

Get origin of a function in io.js and node.js

vkurchatkin/geojson-flow 9

GeoJSON type declarations for Flow

vkurchatkin/generator-foreach 5

forEach for generators

vkurchatkin/connect-compose 4

Compose connect middleware

vkurchatkin/iojs-ru 1

Перевод io.js на русский язык

vkurchatkin/jquery.couch 1

jquery.couch.js for bower

vkurchatkin/8bit.js 0

8Bit.js Audio Library - Write music using 8bit oscillation sounds.

issue commentfacebook/react

Bug: onChange props is being swallowed in Higher-Order-Component

@eakl that's because you are creating InputNode inside of EditableCell. It essentially means that React sees InputNode as a new component on every render, which causes it to be remounted and to lose all state (e.g. focus).

eakl

comment created time in 3 days

pull request commentfacebook/react

Double Invoke Effects in __DEV__

This looks like it might brake a lot of code. This changes implies that effects can only be used when they have very specific semantics: they should either be idempotent or reversible. Also it makes it a requirement to implement a cleanup even if it is never supposed to run.

lunaruan

comment created time in 7 days

issue commentfacebook/react

Bug: Context doesn't work when exported from a package with multiple entrypoints

It is most likely the problem with your build setup, not React. You need to ensure that context that is used by provider is the same this is used by consumer. If your configuration is incorrect, it could happen that the file that creates the context is bundled twice, which essentially makes two different contexts.

ROODAY

comment created time in 8 days

issue commentfacebook/react

Bug: Using HTML entity in JSX is handled weirdly

I don't think this is documented, but this is what Babel has: https://github.com/babel/babel/blob/eea156b2cb8deecfcf82d52aa1b71ba4995c7d68/packages/babel-parser/src/plugins/jsx/xhtml.js

MathiasKandelborg

comment created time in 8 days

issue closedfacebook/react

Bug: weird `useTransition` behaviour

A couple examples of unexpected and seemingly broken useTransition behaviour

1. useTransition doesn't work, if the component is suspended before useTransition call:

Sandbox: https://codesandbox.io/s/gracious-lumiere-242bo?file=/src/First.js

Code:

export default function First() {
  cache.read(); // <-- read from cache first
  const [startTransition, isPending] = React.unstable_useTransition(config); // <-- call useTransition after

  const [rev, setRev] = React.useState(0);

  function reload() {
    cache.expire();

    startTransition(() => {
      setRev(rev => rev + 1);
    });
  }

  return (
    <div>
      {isPending ? "Pending" : "Not pending"}
      <br />
      {rev}
      <br />
      <button onClick={reload}>Reload</button>
    </div>
  );
}

The current behavior

Fallback is always shown

The expected behavior

Fallback is never shown

This issue is somewhat fixed if cache read and useTransition are just swapped, but then we get issue number 2:

2. useTransition prevents fallback, but isPending is either always false, or true for small period of time:

Sandbox: https://codesandbox.io/s/gracious-lumiere-242bo?file=/src/Second.js

Code:

export default function Second() {
  const [startTransition, isPending] = React.unstable_useTransition(config); // <-- call useTransition first
  cache.read();  // <-- read from cache after

  const [rev, setRev] = React.useState(0);

  function reload() {
    cache.expire();

    startTransition(() => {
      setRev(rev => rev + 1);
    });
  }

  return (
    <div>
      {isPending ? "Pending" : "Not pending"}
      <br />
      {rev}
      <br />
      <button onClick={reload}>Reload</button>
    </div>
  );
}

This works much better, but still has some issues

The current behavior

  • fallback is still sometimes shown, mostly when you click the button more than once quickly
  • isPending is either always false, or true for small period of time (you can see the flash)

The expected behavior

  • fallback is never shown
  • isPending is true while suspended

This is probably the same issue as https://github.com/facebook/react/issues/19046

React version: "0.0.0-experimental-4c8c98ab

closed time in 13 days

vkurchatkin

issue commentfacebook/react

Bug: weird `useTransition` behaviour

Ok, I think we can close it. It turned out be more of a discussion than a bug report, but it was truly enlightening.

vkurchatkin

comment created time in 13 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

Also I've noticed that you do need to force a rerender for anything (like I did to trigger a refetch), your code is very likely incorrect

vkurchatkin

comment created time in 13 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

to keep your cache in state

I'm starting to think that is is pretty much the only solution that guarantees correctness when reading from external mutable source, since it allows React to take care of versioning

vkurchatkin

comment created time in 13 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

But the old world is in fact still rendering, correctly, it's just that useTransition is not keeping the pending flag as true while the suspense is resolved.

I guess it makes sense that either this happens or the fallback is shown, since it's impossible to rerender "old world", but with isPending true. What surprises me is that isPending flashes sometimes, but I guess that happens when the "new world" render is committed initially.

vkurchatkin

comment created time in 13 days

issue commentfacebook/react

Bug: React.Lazy not working on Firefox, with HTTPS

@master117 whatever import() does is controlled by webpack

master117

comment created time in 14 days

issue commentfacebook/react

Bug: React.Lazy not working on Firefox, with HTTPS

This has nothing to do with React. React.lazy simply accepts a function that returns a promise. This promise is not created by React itself.

master117

comment created time in 14 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

@josephsavona I see, so essentially the same code that kicks off prefetching also manages prevents cache eviction. I would imagine it somewhat like this:

React.useEffect(() => {
  cache.prefetch(key);
  cache.retain(key);

 return () => {
   cache.release(key);
 };
}, [key]);

Unfortunately, this requires using "render-as-you-fetch" always, but I need to be able to use "fetch-on-render" when needed. "Render-as-you-fetch" is cool in theory, but requires complex infrastructure. It is so much easier to just use "fetch-on-render" and use prefetching as an optimisation technique when needed.

vkurchatkin

comment created time in 16 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

Have you looked at Relay Hooks and its concept of Entrypoints and Fragment References?

I guess I should, thanks for the tip. I'm not very familiar with Relay, but I think it is somewhat what close to what I want to get: mutable shared cache that acts as a source of truth for normalized entities (somewhat like what people do with Redux), but Suspense-enabled.

@josephsavona thanks a lot. A couple of questions:

  1. setCacheState(cache.read()); - not sure how this could work. This inside of a callback, so cache.read() would just throw a promise and nothing would happen. Or am I missing something?

Relay has a mutable cache with support for cache eviction (GC) The key to making this work is to only evict data from the cache once you know it's no longer needed.

Any pointers about that? The only thing I can think of is to use effects to do reference counting of sorts:

const data = cache.read(key);

React.useEffect(() => {
   cache.retain(key);

  return () => {
      cache.release(key);
  };
}, [key]);

This seems to be problematic, since we actually need to call cache.retain(key) much earlier, as soon as we read, preferably, but then we can't actually guarantee that cache.release is going to be called the same number of times, or called at all even.

And finally, are there some set of rules for this stuff, like with everything else for React? So far I see the following:

  1. Cache itself can be mutable (i.e. new Map() is fine)
  2. Cache records can also be mutable, so it is ok if cache.read() returns different values on subsequent renders
  3. Cache records, however, can't be deleted completely until they are used by any component, so if any kind of cache eviction is need, it is required to track the keys that are in use currently and only evict those that are not
vkurchatkin

comment created time in 16 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

Oh maybe something like this:

const [resource, setResource] = React.useState(() => cache.get(key));

const data = resource.read(); 

function reload() {
   cache.expire(key);
   setResource(cache.get(key));
}
vkurchatkin

comment created time in 16 days

issue commentfacebook/react

Bug: weird `useTransition` behaviour

Thanks for the response. This makes a lot of sense and is good reminder that Suspense is very nuanced.

But a mutation like cache.expire() means there is no way to re-render a component in the "old world"

Does this mean that cache should essentially be immutable, or there is a middleground?

One way to model it is to put the cache itself into state of some top-level component.

Unfortunately, that doesn't work for me. I have only one Suspense at the top level at my goal is to never show its fallback after initial render. So all these caches have to be above this Suspense at the very top of the tree, which violates current architecture pretty badly.

How about the following strategy:

const [time] = React.useState(null);
const data = cache.read({ time });  // time means that we want cache record not older than this time
// if time is null then any record is fine
 
function reload() {
    cache.expire(); // doesn't delete the record, but updates it's expiration time to current time

   startTransition(() => {
        setTime(Date.now());
   });
}

// ...

There is a lot to work out there, which is part of the reason we're not yet releasing Suspense for data fetching for broad consumption.

I know that, but I'm willing to be an early adopter and prepared for the consequences.

vkurchatkin

comment created time in 16 days

issue openedfacebook/react

Bug: weird `useTransition behaviour`

A couple examples of unexpected and seemingly broken useTransition behaviour

1. useTransition doesn't work, if the component is suspended before useTransition call:

Sandbox: https://codesandbox.io/s/gracious-lumiere-242bo?file=/src/First.js

Code:

export default function First() {
  cache.read(); // <-- read from cache first
  const [startTransition, isPending] = React.unstable_useTransition(config); // <-- call useTransition after

  const [rev, setRev] = React.useState(0);

  function reload() {
    cache.expire();

    startTransition(() => {
      setRev(rev => rev + 1);
    });
  }

  return (
    <div>
      {isPending ? "Pending" : "Not pending"}
      <br />
      {rev}
      <br />
      <button onClick={reload}>Reload</button>
    </div>
  );
}

The current behavior

Fallback is always shown

The expected behavior

Fallback is never shown

This issue is somewhat fixed if cache read and useTransition are just swapped, but then we get issue number 2:

2. useTransition prevents fallback, but isPending is either always false, or true for small period of time:

Sandbox: https://codesandbox.io/s/gracious-lumiere-242bo?file=/src/Second.js

Code:

export default function Second() {
  const [startTransition, isPending] = React.unstable_useTransition(config); // <-- call useTransition first
  cache.read();  // <-- read from cache after

  const [rev, setRev] = React.useState(0);

  function reload() {
    cache.expire();

    startTransition(() => {
      setRev(rev => rev + 1);
    });
  }

  return (
    <div>
      {isPending ? "Pending" : "Not pending"}
      <br />
      {rev}
      <br />
      <button onClick={reload}>Reload</button>
    </div>
  );
}

This works much better, but still has some issues

The current behavior

  • fallback is still sometimes shown, mostly when you click the button more than once quickly
  • isPending is either always false, or true for small period of time (you can see the flash)

The expected behavior

  • fallback is never shown
  • isPending is true while suspended

React version: "0.0.0-experimental-4c8c98ab

created time in 16 days

issue commentfacebook/react

Bug: The trigger timing of "child useEffect" is different in chrome and safari.

Many reasons why this is not a bug:

  • you are not allowed to make side effects in render. If you do that, the outcome is essentially "undefined behaviour", that is, nothing is guaranteed

  • React provides no guarantees about timing of useEffect with respect to render anyway.

So while this is an inconsistency and it could be fixed, there is not good reason to do so.

xiaoshuangLi

comment created time in 21 days

issue commentfacebook/react

Bug: Presence of useEffect hook (even with empty function) significantly slows render time compared to useCallback hook

Saying something like "That is sort of expected. Nowhere is says that useEffect is free in terms of performance" isn't a useful comment

This wasn't intended to answer the question "why such a difference exists", I was trying to point that this is not a valid bug report. Maybe useEffect could be faster, but the only way to make such a claim is to point out exactly how it could be made faster.

gregjacobs

comment created time in 25 days

issue commentfacebook/react

Bug: Presence of useEffect hook (even with empty function) significantly slows render time compared to useCallback hook

Especially when useCallback() doesn't produce the same issue?

This is irrelevant, these two hooks do completely different things

I expect there to be a slight performance hit (after all, React is doing more work), but I don't expect a ~2x slowdown in rendering performance.

What is your reasoning, what makes you think it can/should be faster?

gregjacobs

comment created time in 25 days

issue commentfacebook/react

Bug: Presence of useEffect hook (even with empty function) significantly slows render time

That is sort of expected. Nowhere is says that useEffect is free in terms of performance

gregjacobs

comment created time in 25 days

issue commentfacebook/react

Provide syntactic sugar for suspense fallback

I thought the purpose of Suspense is to have a semantic way of representing what should be rendered in place of a component which is not yet ready to get rendered.

The point of Suspense is to prevent the user from seeing too many loading states or fallbacks. This is achieved by the fact that a single <Suspense> boundary can have many suspending children. So, there are many components that need to fetch some data, but only a few places that can show fallbacks.

voliva

comment created time in a month

issue commentfacebook/react

Provide syntactic sugar for suspense fallback

This a text book case for a HOC:

const SuspenseProfileTimeline = withSuspense(ProfileTimeline, (props) => <div>Loading posts...</div>)

That said, it shouldn't be commonly needed, since it almost entirely defeats the purpose of Suspense

voliva

comment created time in a month

issue commentfacebook/react

Bug: Functional component rerender when same state

@heecheolman once again, quote from the same page

Note that React may still need to render that specific component again before bailing out. That shouldn’t be a concern because React won’t unnecessarily go “deeper” into the tree.

Which means that when you call setState with the same value it is not guaranteed that the function is not going to be called again, but even if it is, it is not an actual rerender, since child components are not going to be rerendered.

heecheolman

comment created time in a month

issue commentfacebook/react

Bug: Functional component rerender when same state

This is documented here: https://reactjs.org/docs/hooks-reference.html#bailing-out-of-a-state-update

Note that React may still need to render that specific component again before bailing out.

heecheolman

comment created time in a month

issue commentfacebook/react

Bug: checked attribute doesn't change in DOM even though Reach handles it's state correctly

The question is: why does that matter to you?

jdolearydl

comment created time in a month

issue commentfacebook/react

Imperative attack on react design: immerjs produceWithPatches

So there is really nothing to worry about. If this pattern is somehow bad, it doesn't seem like a popular one that requires specific mention in React docs.

andrew-aladev

comment created time in a month

issue commentfacebook/react

Imperative attack on react design: immerjs produceWithPatches

Can you point to any library, other than Slate, that uses this pattern?

andrew-aladev

comment created time in a month

issue commentfacebook/react

Imperative attack on react design: immerjs produceWithPatches

It seems that you don't like API design of a specific library, which has nothing to do with immer (because the same can be done without it) or React itself.

andrew-aladev

comment created time in a month

issue commentfacebook/react

Imperative attack on react design: immerjs produceWithPatches

There is nothing wrong with this approach. A lot of components only take defaultValue as a prop and don't react to changes to this prop after initial render.

andrew-aladev

comment created time in a month

issue commentfacebook/react

[eslint-plugin-react-hooks] react-hooks/exhaustive-deps throws lint error `Pass an inline function` for valid scenarios

useCallback is specifically designed for inline functions. For cases like this you need to use useMemo:

 const throttledMethod = React.useMemo(
        () => _.throttle(abc, 500 ),
        [abc],
    );
hiteshdua1

comment created time in a month

issue commentfacebook/react

Bug: Weird rerender behavior with render prop and context

It rerenders regardless when parent rerenders and the propsAreEqual call back is not even called.

That most likely means that your component is simply unmounted and remounted by the Tooltip component.

sidecus

comment created time in a month

issue commentfacebook/react

Bug: Weird rerender behavior with render prop and context

I don't see anything unexpected here:

Here React.memo is used incorrectly, you are comparing prop objects instead of comparing props one by one. You should just omit the second argument.

const MemoedTitleWithRenderProp = React.memo(TitleWithRenderProp, (prev, next) => {
    return prev === next;
});

This component rerenders because because its parent component is rerendered. You need to use React.memo to avoid that.

const AddNumberToContext = ({toAdd, children} : {toAdd: number, children: (result: number) => JSX.Element}) => {
    const context = React.useContext(Context);
    console.log('AddNumberToContext rendering');
    return children(context + toAdd);
};
sidecus

comment created time in a month

PR merged vkurchatkin/function-origin

Fix bound functions
  • without this fix accessing the file property of the returned function origin of a bound function crashes the process

Additionally removed a test that no longer passes with latest v8 as it has gotten smarter:

  • v8 has improved and with latest node the function name is resolved to 'assignedFunction'
  • additionally that assert wasn't really testing function-origin functionality
+23 -2

3 comments

2 changed files

thlorenz

pr closed time in 2 months

push eventvkurchatkin/function-origin

Thorsten Lorenz

commit sha 8673a5d9e5209fff4802dff13a11ad4d5146c990

fix: bound function resolution - without this fix accessing the `file` property of the returned function origin of a bound function crashes the process

view details

Thorsten Lorenz

commit sha 5dc1de4ed23690c0e59b3c3d1fafbbcfce7f9dd1

test: removing test that asserted v8 does not assign name of assigned function - v8 has improved and with latest node the function name is resolved to 'assignedFunction' - additionally that assert wasn't really testing function-origin functionality

view details

Vladimir Kurchatkin

commit sha fcc19b28402e84a9c5d0181a3b6f871c868e4609

Merge branch 'fix-bound-functions' of https://github.com/thlorenz/function-origin

view details

Vladimir Kurchatkin

commit sha e0564cdf4230150af190117c46a1ad8c22ab90ab

Fixup

view details

push time in 2 months

push eventvkurchatkin/function-origin

Vladimir Kurchatkin

commit sha c5a6fe9b22ecbac49a00aa53ff244167a0817c9c

Clean up tests

view details

push time in 2 months

push eventvkurchatkin/function-origin

Vladimir Kurchatkin

commit sha 118e551752cae0eb04daa38c5e6e01879f766057

Compatibiliy with Node 14

view details

push time in 2 months

push eventvkurchatkin/function-origin

Josh Wulf

commit sha 06e8f1fa1db1d37dfd4ff986d07ff7471ae69dd7

Fix for Node 12

view details

Vladimir Kurchatkin

commit sha 8d988dd53a5a4447ed716748946bcf18c4a704b7

Merge pull request #10 from jwulf/node-12 Fix for Node 12. Fixes #9

view details

push time in 2 months

issue closedvkurchatkin/function-origin

Build failed with nodejs >= 12

Hello

$ npm i function-origin

> function-origin@1.1.1 install /home/schroeterm/devel/westeros-dev/node_modules/test/node_modules/function-origin
> node-gyp rebuild

make : on entre dans le répertoire « /home/schroeterm/devel/westeros-dev/node_modules/test/node_modules/function-origin/build »
  CXX(target) Release/obj.target/function_origin/src/function_origin.o
In file included from ../src/function_origin.cc:2:
../../nan/nan.h: In function ‘void Nan::AsyncQueueWorker(Nan::AsyncWorker*)’:
../../nan/nan.h:2298:62: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type]
     , reinterpret_cast<uv_after_work_cb>(AsyncExecuteComplete)
                                                              ^
../src/function_origin.cc: In function ‘Nan::NAN_METHOD_RETURN_TYPE SetOrigin(Nan::NAN_METHOD_ARGS_TYPE)’:
../src/function_origin.cc:11:79: warning: ‘bool v8::Object::Set(v8::Local<v8::Value>, v8::Local<v8::Value>)’ is deprecated: Use maybe version [-Wdeprecated-declarations]
   target->Set(Nan::New<String>("file").ToLocalChecked(), origin.ResourceName());
                                                                               ^
In file included from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8-internal.h:14,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:25,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:63,
                 from ../src/function_origin.cc:1:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:3372:22: note: declared here
                 bool Set(Local<Value> key, Local<Value> value));
                      ^~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8config.h:311:3: note: in definition of macro ‘V8_DEPRECATED’
   declarator __attribute__((deprecated(message)))
   ^~~~~~~~~~
../src/function_origin.cc:14:49: warning: ‘bool v8::Object::Set(v8::Local<v8::Value>, v8::Local<v8::Value>)’ is deprecated: Use maybe version [-Wdeprecated-declarations]
     Nan::New<Integer>(fn->GetScriptLineNumber()));
                                                 ^
In file included from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8-internal.h:14,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:25,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:63,
                 from ../src/function_origin.cc:1:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:3372:22: note: declared here
                 bool Set(Local<Value> key, Local<Value> value));
                      ^~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8config.h:311:3: note: in definition of macro ‘V8_DEPRECATED’
   declarator __attribute__((deprecated(message)))
   ^~~~~~~~~~
../src/function_origin.cc:17:51: warning: ‘bool v8::Object::Set(v8::Local<v8::Value>, v8::Local<v8::Value>)’ is deprecated: Use maybe version [-Wdeprecated-declarations]
     Nan::New<Integer>(fn->GetScriptColumnNumber()));
                                                   ^
In file included from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8-internal.h:14,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:25,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:63,
                 from ../src/function_origin.cc:1:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:3372:22: note: declared here
                 bool Set(Local<Value> key, Local<Value> value));
                      ^~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8config.h:311:3: note: in definition of macro ‘V8_DEPRECATED’
   declarator __attribute__((deprecated(message)))
   ^~~~~~~~~~
../src/function_origin.cc:19:87: warning: ‘bool v8::Object::Set(v8::Local<v8::Value>, v8::Local<v8::Value>)’ is deprecated: Use maybe version [-Wdeprecated-declarations]
   target->Set(Nan::New<String>("inferredName").ToLocalChecked(), fn->GetInferredName());
                                                                                       ^
In file included from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8-internal.h:14,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:25,
                 from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:63,
                 from ../src/function_origin.cc:1:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:3372:22: note: declared here
                 bool Set(Local<Value> key, Local<Value> value));
                      ^~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8config.h:311:3: note: in definition of macro ‘V8_DEPRECATED’
   declarator __attribute__((deprecated(message)))
   ^~~~~~~~~~
../src/function_origin.cc: At global scope:
../src/function_origin.cc:22:18: error: variable or field ‘Init’ declared void
 static void Init(Handle<Object> exports) {
                  ^~~~~~
../src/function_origin.cc:22:18: error: ‘Handle’ was not declared in this scope
../src/function_origin.cc:22:18: note: suggested alternative: ‘rand_r’
 static void Init(Handle<Object> exports) {
                  ^~~~~~
                  rand_r
../src/function_origin.cc:22:31: error: expected primary-expression before ‘>’ token
 static void Init(Handle<Object> exports) {
                               ^
../src/function_origin.cc:22:33: error: ‘exports’ was not declared in this scope
 static void Init(Handle<Object> exports) {
                                 ^~~~~~~
In file included from ../src/function_origin.cc:1:
../src/function_origin.cc:27:30: error: ‘Init’ was not declared in this scope
 NODE_MODULE(function_origin, Init)
                              ^~~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:560:36: note: in definition of macro ‘NODE_MODULE_X’
       (node::addon_register_func) (regfunc),                          \
                                    ^~~~~~~
../src/function_origin.cc:27:1: note: in expansion of macro ‘NODE_MODULE’
 NODE_MODULE(function_origin, Init)
 ^~~~~~~~~~~
../src/function_origin.cc:27:30: note: suggested alternative:
 NODE_MODULE(function_origin, Init)
                              ^~~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:560:36: note: in definition of macro ‘NODE_MODULE_X’
       (node::addon_register_func) (regfunc),                          \
                                    ^~~~~~~
../src/function_origin.cc:27:1: note: in expansion of macro ‘NODE_MODULE’
 NODE_MODULE(function_origin, Init)
 ^~~~~~~~~~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:217:18: note:   ‘node::Init’
 NODE_EXTERN void Init(int* argc,
                  ^~~~
In file included from /home/schroeterm/.cache/node-gyp/12.10.0/include/node/node.h:63,
                 from ../src/function_origin.cc:1:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h: In instantiation of ‘void v8::PersistentBase<T>::SetWeak(P*, typename v8::WeakCallbackInfo<P>::Callback, v8::WeakCallbackType) [with P = node::ObjectWrap; T = v8::Object; typename v8::WeakCallbackInfo<P>::Callback = void (*)(const v8::WeakCallbackInfo<node::ObjectWrap>&)]’:
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/node_object_wrap.h:84:78:   required from here
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:9893:16: warning: cast between incompatible function types from ‘v8::WeakCallbackInfo<node::ObjectWrap>::Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<node::ObjectWrap>&)’} to ‘Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<void>&)’} [-Wcast-function-type]
                reinterpret_cast<Callback>(callback), type);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h: In instantiation of ‘void v8::PersistentBase<T>::SetWeak(P*, typename v8::WeakCallbackInfo<P>::Callback, v8::WeakCallbackType) [with P = Nan::ObjectWrap; T = v8::Object; typename v8::WeakCallbackInfo<P>::Callback = void (*)(const v8::WeakCallbackInfo<Nan::ObjectWrap>&)]’:
../../nan/nan_object_wrap.h:65:61:   required from here
/home/schroeterm/.cache/node-gyp/12.10.0/include/node/v8.h:9893:16: warning: cast between incompatible function types from ‘v8::WeakCallbackInfo<Nan::ObjectWrap>::Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<Nan::ObjectWrap>&)’} to ‘Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<void>&)’} [-Wcast-function-type]
make: *** [function_origin.target.mk:109: Release/obj.target/function_origin/src/function_origin.o] Error 1
make : on quitte le répertoire « /home/schroeterm/devel/westeros-dev/node_modules/test/node_modules/function-origin/build »
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/schroeterm/.npm-packages/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:196:23)
gyp ERR! stack     at ChildProcess.emit (events.js:209:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Linux 4.19.0-6-amd64
gyp ERR! command "/usr/bin/node" "/home/schroeterm/.npm-packages/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/schroeterm/devel/westeros-dev/node_modules/test/node_modules/function-origin
gyp ERR! node -v v12.10.0
gyp ERR! node-gyp -v v5.0.3
gyp ERR! not ok 
npm WARN test@1.0.0 No description
npm WARN test@1.0.0 No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! function-origin@1.1.1 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the function-origin@1.1.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/schroeterm/.npm/_logs/2019-10-01T12_32_59_341Z-debug.log

closed time in 2 months

Skywalker13

PR merged vkurchatkin/function-origin

Fix for Node 12. Fixes #9

This fixes the Node 12 incompatibility.

+8 -5

1 comment

1 changed file

jwulf

pr closed time in 2 months

push eventvkurchatkin/function-origin

Vladimir Kurchatkin

commit sha 650171c47c079653421de60f0c613aace86c79ca

Added .travis.yml

view details

push time in 2 months

issue commentfacebook/react

Anomaly in rendering of self closing versus explicit opening and closing of the same custom tag.

Its not about props and children, if about self closing of tags and their explicit opening and closing behavioral anomaly.

There is no anomaly. Self-closing elements and explicitly opened and closed elements are compiled to exactly the same code.

Samarth484

comment created time in 2 months

issue commentfacebook/react

Anomaly in rendering of self closing versus explicit opening and closing of the same custom tag.

This renderers Entry with 4 props

  <Entry
      key={emojiTerm.id}
      emoji={emojiTerm.emoji}
      name={emojiTerm.name}
      meaning={emojiTerm.meaning}
    >
    </Entry>

This renderers Entry with a bunch of text as children

  <Entry>
      key={emojiTerm.id}
      emoji={emojiTerm.emoji}
      name={emojiTerm.name}
      meaning={emojiTerm.meaning}
    </Entry>
Samarth484

comment created time in 2 months

issue commentfacebook/react

Bug: setState does not rerender a functional component when an object's property is deleted

React detects state changes by comparing old state with new state. If it is the same object it infers that no render is required

taimoorgit

comment created time in 2 months

issue commentfacebook/react

Bug: setState does not rerender a functional component when an object's property is deleted

That is not a bug. You return the same object => no rerender. You should create a new object instead

taimoorgit

comment created time in 2 months

issue commentfacebook/react

Feature Request: linter for hook order like sort-comp

You can't generally sort hooks since they can depend on each other.

daveisfera

comment created time in 2 months

issue commentfacebook/react

Bug: Invalid hook call in React Native; verified all known causes

Also it's somewhat unclear from your post, but if you are actually using React Native, then React 16.11 should be the right version

Tycholiz

comment created time in 2 months

issue commentfacebook/react

Bug: Invalid hook call in React Native; verified all known causes

There is no way to tell without a complete example.

Tycholiz

comment created time in 2 months

issue commentfacebook/react

Bug: useState with ResizeObserver leaks React components on Safari 13.1

Investigating it as React bug seems pointless for a simple reason:

const x = React.useState(false) couldn't be possibly distinguished from React.useState(false) by React even if it tried to, it is simply not possible to detect if a value is assigned to something or not. So, from point of view of JavaScript code, this two snippets are identical.

luketmillar

comment created time in 2 months

issue commentfacebook/react

Bug: useState with ResizeObserver leaks React components on Safari 13.1

There is no reason to assume a bug in React. If there is an actual leak, bug in Safari is most likely

luketmillar

comment created time in 2 months

issue commentfacebook/react

Bug: useReducer initialState does not create a new object

The solution for my example ☝🏼 hook above is to do this: useReducer(reducer, { ...initialState }) so that a new object reference is created every time this hook is used.

This is a good demonstration why current behaviour is the best: you are making a shallow copy, so it doesn't really protect from mutating the state. You need to make deep copy to achieve that, bu there is no generic way to do that correctly.

crobinson42

comment created time in 2 months

issue commentJSMonk/hegel

Unsound `await` handling

Let's say there is a generic type for that called $Await<T> which is supposed to evaluate to the type of expression await x where x has type T.

T can be one of the following

Thenable<T>

interface Thenable<T> {
  then<T>(fn: (val: T) => unknown): unknown;
}

For thenables, $Await<Thenable<T>> equals $Await<T>.

False-thenable

False-thenable is an object, for which obj.then evaluates to a function, but it's not actually a thenable. Applying $Await to a false-thenable makes no sense, since there is no way to evaluate it.

Non-thenable

For everything else $Await<T> equals T;

So here is a possible way to deal with that. await x (or Promise.resolve(x) or other) evaluates to type $Await<T>. Type $Await<T> can be further refined if we have additional information about T. If T is known to be a thenable, we evaluate $Await<Thenable<T>> to $Await<T> recursively. If T is known to be a non-thenable, $Await<T> evaluate to T. Otherwise $Await<T> should stay opaque, since there is no way to tell what it is.

Additionally, it should be illegal to await on values, that could possibly be false-thenables. Here is an example:

async function test(x: unknown) {
  await x; // This should not be allowed
}


const obj = {
  then(str: string) {
    return str.toLowerCase(); // runtime error
  }
}

test(obj);
vkurchatkin

comment created time in 2 months

issue commentJSMonk/hegel

Unsound `await` handling

Not really fixed though. A tiny modification and you get the same thing:

async function foo<T>(val: T): Promise<T> {
  const v = await val;
  return v;
}

async function test() {
  const promise: Promise<1> | string = Promise.resolve(1);
  const val = await foo(promise);

  if (typeof val !== 'string') {
    const a = val.then(); // Runtime error
  }
}

test();
vkurchatkin

comment created time in 2 months

issue commentfacebook/react

Bug: Incorrect HTML attribute name for custom tags

Use class instead of className

Enter-tainer

comment created time in 2 months

issue commentfacebook/react

Bug: functional components are not re-rendered if the provided props look the same

This works just fine. If you call setState with the value equal to the current state, it might not rerender the current component because nothing have changes. This is expected

danielo515

comment created time in 2 months

issue commentfacebook/react

Bug: state could be reset into the initialValue when using StrictMode

Isn't it supposed to throw some warnings, not break an application without any notice?

Is shows warning when you are using deprecated APIs and such. The idea of double-invoking is exactly that it might break something without any notice.

theKashey

comment created time in 2 months

issue commentfacebook/react

Bug: state could be reset into the initialValue when using StrictMode

StrictMode is not "refs-compatible", and it's not safe to use it.

StrictMode is "refs-compatible", but you need to follow the rules around refs, e.g. not mutating them in render (except for lazy initialization)

react is not reporting about the issue with Strict it might discovered.

Unfortunately, that's not possible. StrictMode doesn't have any idea it has discovered anything. It is up to the developer to figure that out.

theKashey

comment created time in 2 months

issue commentfacebook/react

Bug: state could be reset into the initialValue when using StrictMode

The idea of StrictMode that it double renders (among other things) all components trying to catch some unintended side-effects. So, if something works without StrictMode, but breaks with it then here you go: you just found a bug in your code! (or in your case, in react-stripe-js)

theKashey

comment created time in 2 months

issue commentfacebook/react

Bug: Sometimes useEffect() callback is called before render

It's hard to tell exactly, but various work can affect the way a browser batches painting that can essentially disable transitions like this. You can read more about it here: https://github.com/reactjs/react-transition-group/issues/159

ildar-icoosoft

comment created time in 2 months

issue commentfacebook/react

Bug: Sometimes useEffect() callback is called before render

This has nothing to do with React, that's just how CSS transitions work

ildar-icoosoft

comment created time in 2 months

issue commentJSMonk/hegel

Incorrect type refinement of strict equality operator

This has nothing to do with refinement, it is an inference bug. This yields the same error.

function isEmptyString(a) {
    a === '';
}

const isEmpty = isEmptyString('hello')

In reality a shouldn't even be inferred as string, it should be unknown or unconstrained generic.

leushkin

comment created time in 2 months

issue commentfacebook/react

startTransition bails early

How does it confirm the opposite? Without startTransition, the ui suspends, and the fallback renders

I meant that I don't see fallback at all. Actually after playing with it, it shows sometimes, but mostly there is no fallback at all after click

arackaf

comment created time in 2 months

issue commentfacebook/react

startTransition bails early

Click the "Reload" button. startTransition will be called, the query will reload over the wire, suspending in the process, but the pending indicator does not stay true.

It actually seems to confirm the opposite. There really should be a way to reproduce this without graphql stuff.

arackaf

comment created time in 2 months

issue commentJSMonk/hegel

How to write a clone function?

Interestingly, this simply crashes:

function clone<T>(arr: Array<T>): Array<T> {
    const array: Array<T> = Array.from(arr);
    return array;
}
mohsen1

comment created time in 3 months

issue commentJSMonk/hegel

Refinements should be invalidated by side effects

I guess if soundness is the goal, then there is no middle ground

vkurchatkin

comment created time in 3 months

issue commentJSMonk/hegel

refine type of array access to non-undefined given proper for-loop header

There is no way to avoid this check, unless we go into the realm of dependent types

trusktr

comment created time in 3 months

issue commentJSMonk/hegel

Refinements should be invalidated by side effects

You are right. There are a couple of thing that can be done

  1. Purity tracking. Functions that are free of side effects should be marked as such. Properties that are definitely not getters.

  2. Visibilty tracking. This is probably very convoluted in practice. The idea is to prove that a given statement can't possible affect a given refinement, because it doesn't see the refined binding or value.

Simple example:

import { foo } from 'foo';

export function test(x: string | number) {
    if (typeof x === 'string') {
       foo(); // foo is from outer scope, so there is no way it can affect x
    }
}

But this will become convoluted very quickly:

import { foo, bar } from 'foo';

export function test(x: string | number) { bar(() => x = 1);

if (typeof x === 'string') {
   foo(); // foo is from outer scope, but current scope has leaked through `bar`
}

}

vkurchatkin

comment created time in 3 months

issue commentJSMonk/hegel

Unsound `await` handling

Sorry, typo. Fixed the example

vkurchatkin

comment created time in 3 months

issue openedJSMonk/hegel

Unsound `await` handling

async function foo<T>(val: T) {
  const v = await val;
  return v;
}

async function test() {
  const promise = Promise.resolve(1);
  const val = await foo(promise);
  const a = promise.then(); // Runtime error
}

I assume that await and similar promise methods have signature like this:

await<T>(Promise<T> | T) => T;

This is incorrect. If type of T is not known to be a promise (i.e. unknown or generic T), it is assumed NOT to be a promise, while at runtime it could be a promise.

created time in 3 months

issue commentJSMonk/hegel

Incorrect refinement using `instanceof`

That is a separate issue. Refinement is still incorrect

vkurchatkin

comment created time in 3 months

issue commentJSMonk/hegel

Unsound type inference with arithmetic operators

but generics should not allow usage of unions

They should allow it, but that's not what should be inferred in this case.

vkurchatkin

comment created time in 3 months

issue openedJSMonk/hegel

Subtyping functions with optional arguments is unsound

function foo(x: ?string) {
  if (x !== undefined) {
    const val = x.toLowerCase();
  }
}

const foo_: () => undefined = foo; // Either this
const foo__: (x: number) => undefined = foo_; //  or this shouldn't be allowed

foo__(1); // runtime error

created time in 3 months

issue openedJSMonk/hegel

Refinements should be invalidated by side effects

const a:  { a: string | number } = { a: 'foo' };

function foo() {
  a.a = 1;
}

function test(x: { a: string | number }) {
    if (typeof x.a === 'string') {
      foo(); // this invalidates the refinement
      const a: string = x.a.toUpperCase(); // runtime error
    }
}

 test(a);

created time in 3 months

issue openedJSMonk/hegel

Inference doesn't work with recursive functions

function factorial(a) {
  if (a === 1) {
    return 1;
  }

  return a * factorial(a - 1);
}

created time in 3 months

issue openedJSMonk/hegel

Unsound subclassing is allowed

class A {
  foo() {
    return 1;
  }
}

class B extends A {
  foo() {
    return ''; // this shouldn't be allowed
  }
}

const b: A = new B;
const val = b.foo().toFixed(); // runtime error

created time in 3 months

issue openedJSMonk/hegel

Incorrect refinement using `instanceof`

Example:

class A {
  foo(x: string) {
  }
}

class B extends A {
  foo(x: number) {
    return x.toFixed();
  }
}

function test(a: A | B | {}) {
  if (a instanceof A) {
    a.foo('')
  }
}

a is refined to be an A instead of A | B, which leads to a runtime error.

created time in 3 months

issue openedJSMonk/hegel

Unsound type inference with '+' operator

Consider the following function:

let f = (a, b) => a + b

The inferred type is

<T: bigint | number | string>(T, T) => T

This might seem correct, but actually is unsound:

let f = (a, b) => a + b

const a: number | bigint = 1;
const b: number | bigint = 1n;

const x = f(a, b); // TypeError thrown

created time in 3 months

issue commentfacebook/react

Bug: Typing Fast into Controlled Input doesn't change value visually immediately

Well, I guess the devtools are able to observe these changes faster then your app can process them. That is surprising to me, but still unrelated to React.

anatolzak

comment created time in 3 months

issue commentfacebook/react

Bug: Typing Fast into Controlled Input doesn't change value visually immediately

Well, seems like the problem with your app then.

anatolzak

comment created time in 3 months

issue commentfacebook/react

Bug: Typing Fast into Controlled Input doesn't change value visually immediately

There is no way to tell, unless you provide your code

anatolzak

comment created time in 3 months

issue openedreactjs/rfcs

[Feature request] error handling in useTransition

I propose adding the ability to handle errors in useTransition.

Example

const [startTransition, isPending] = useTransition({
    timeoutMs: 3000
 });

const [state, setState] = React.useState();

function loadData() {
   startTransition((controller) => {
      setState('foo');

      return {
          onError: (err) => {
               alert('Failed to fetch the data!');
               controller.abort();
           }
      };
   }

Explanation

Callback object

The function that is passed to startTransition returns a callback object, that can be used to notify the caller about transition state changes. onError is called if the corresponding Suspense boundary caught and error while rendering this transition.

Controller object

The function that is passed to startTransition receives a controller object, that can be use to abort transition. controller.abort() can be called at any time before the transition is complete. If it is called when transition is pending, the whole suspended "branch" is discarded, as if the transition never started.

If controller.abort() is called in onError handler, this prevents the error from propagating to ErrorBoundary.

created time in 3 months

issue commentfacebook/react

Bug: useState's setState may change your state to 'undefined'

It seems that your state is a function. In that case, setState(state) won't work as expected

LXSMNSYC

comment created time in 3 months

more