profile
viewpoint

cucapra/lambdalab 8

interactive λ-calculus for learning

dsainati1/maxflow 1

An implementation of Ford-Fulkerson/Edmonds-Karp in OCaml

apurvsethi/cs3152group3 0

CS 3152 (Spring 2016) Game

dsainati1/KAT 0

Implementation of an equality checker for two expressions in Kleene Algebra (Final Project for CS 6861)

dsainati1/oauth2orize 0

OAuth 2.0 authorization server toolkit for Node.js.

issue commentfacebook/flow

String is not a valid ComponentType

What you are looking for is React.ElementType which is the type of all things that can be inputs to a React element (strings and components).

danielo515

comment created time in 12 days

issue closedfacebook/flow

String is not a valid ComponentType

Hello I creating a component that takes a component to render as props. However, it's being impossible for me to type that it can accept both react components and default components (those defined by strings). Flow says that string is not a valid type for ComponentType

// @flow
import * as React from "react";


type Props = {
  component: React.ComponentType<*>
}
  
const Bla = ({component: C }: Props) => <C/>

Bla.defaultProps = {
  component: 'div'
}

const x = <Bla/>

Flow version: 0.125.1

Expected behavior

I expect string to be a valid component

Actual behavior

Only react components can be used

  • Link to Try-Flow or Github repo: https://flow.org/try/#0PTAEAEDMBsHsHcBQBLAtgB1gJwC6gFSgCGAzqAEoCmRAxnpFrKqAERbV0sDcivOAnukqgACo3RkAvKADeiUKBpNMAO0oqcALgoccAOgDCy2Go0AVQZQA8+AHyIAvvNCIlKkngBC0IqGkAKGSUME3UtUANQB20xWAkASj9bUCsDYHtEbyI9ABNKSCIAV2gcWIk-WWdg1TDtAHIc5AA3OsdeNw9QAA8Kqyz0oA

closed time in 12 days

danielo515

issue commentfacebook/flow

Type refinement stopped working in 0.125

Good catch. Working on a fix

frontendphil

comment created time in 13 days

issue closedfacebook/flow

empty type is treated as any

Flow version: 0.125.1

Expected behavior

empty to behave like mixed (does not cast to anything only refinements are allowed)

Actual behavior

empty is basically alias to any

code

declare var nothing: empty
declare var something: 'cotne'

declare function giveMeNumber(number): void


giveMeNumber(1)// ok
giveMeNumber('cotne')// error as expected

giveMeNumber(nothing)// should error

if (something !== 'cotne') {
  giveMeNumber(something)// should error
}

Try

closed time in 13 days

thecotne

issue commentfacebook/flow

empty type is treated as any

In this case empty is behaving as designed, that is to say, the exact opposite way as mixed. In Flow, mixed is the top type, the supertype of all other types. This means you cannot assume anything about its contents, but can create it from any value. For example, all of the following are legal: let x : mixed = 3, let x : mixed = {} and let x : mixed = () => {}, while all of the following are errors (assuming x has type mixed): x.foo, x() and x = x + 1. Put another way, you can write anything to a mixed value, but cannot read anything from it.

empty has the opposite behavior: it is the bottom type in Flow, the subtype of all other types. It is impossible to create, but if you obtain a value of type empty, you can do anything with it. So to contrast with the examples above, all of the following are errors: let x : empty = 3, let x : empty = {} and let x : empty = () => {}, while all of the following (assuming x has type empty) are legal: x.foo, x() and x = x + 1. Reading and writing empty are dual to mixed, you can read anything from an empty value, but cannot write anything to it.

In the example above, you can call giveMeNumber inside that refinement because Flow knows that the if statement will never succeed, so the code inside is dead; dead code is one of the only sources of empty in Flow. As such, the above code won't error because that function won't even get called.

As an aside, the reason any is an unsafe type is because it combines the permissibility of writing to mixed and reading from empty: you can put anything into an any value, and do anything you want with it.

thecotne

comment created time in 13 days

issue closedfacebook/flow

React: Flow cannot infer generic type of HOC

Flow version: v0.121.0 (and earlier versions)

UPDATE: I've reduced the repro case and title from the original post following Jack's first comment below.

When using HOCs in React, I'm struggling to get flow to infer generic types. Take for instance this case where I'm using the "trivialHOC" example from the docs:

import React, { type AbstractComponent } from 'react';

function trivialHOC<Config>(Component: AbstractComponent<Config>): AbstractComponent<Config> {
  return Component;
}

const DemoComponent = () => <div />;

const WrappedDemoComponent = trivialHOC(DemoComponent);

Error is on the call to trivialHOC(DemoComponent):

Missing type annotation for `Config`. `Config` is a type parameter declared in  function [1] and was implicitly instantiated at  call of `trivialHOC` [2].

I'm not sure if it's a red herring, but I noticed that this error only repros when I export the wrapped component (export default WrappedDemoComponent;). Otherwise flow seems happy with it.

Expected behavior:

Flow should be able to infer the type of the component as it's passed into trivialHOC and it should correctly return a component of type AbstractComponent<Config>.

Actual behavior

Flow cannot infer the inbound type and therefore complains that no generic type has been provided.

  • Link to Try-Flow or Github repo: https://flow.org/try/#0PTAEAEDMBsHsHcBQBLAtgB1gJwC6gEoCmAhgMY4A0oA3qDgJ7qGgCCARgM45Zk4DCsDLAB2hYXgC+oSFkGgA5FhLl5AbkSJIAV2HlkIulmQA3ZMWgAJAPJ8APAOGRkAcwB8ACgFDR4gFytObl4vTB8cexEnNwBKf3YuHnIQkTFwhyjXGkRQUCUcLSxhUGSw9QkNUhEuUAARQlRYEtTQAF5Qd2jWzNsAExNQYFd1RErhaoB1HnQmHrqGpvFWwxMzSxt3OcbBUNTo4ZBQABUAC2ZCLFksUD6OYmmSLA5QZEhQelgtUErUVGaPvBwx2QT1EAA88NBkKJfIhCKDMLhroRIMQtNA8JM7jNNgscOogA

closed time in 2 months

btraut

issue commentfacebook/flow

React: Flow cannot infer generic type of HOC

This has to do with the variance of these generics (https://flow.org/en/docs/lang/variance/). The Config generic appears contravariantly in the definition of AbstractComponent, and thus contravariantly in the type of the argument of your HOC. By contrast the T generic appears covariantly in the type of val.

We specifically do not allow you to export inferred contravariant positions, because it becomes impossible to know how much the type will widen when used in different files. Notice that the error disappears if you don't try to export fooA.

btraut

comment created time in 2 months

created tagflowtype/flow-bin

tagv0.120.1

Binary wrapper for Flow - A static type checker for JavaScript

created time in 3 months

push eventflowtype/flow-bin

Daniel Sainati

commit sha 34275ca5d09af7f6468a4d4054cfe7ed746706ad

v0.120.1

view details

push time in 3 months

issue commentflowtype/flow-bin

Flow server reporting wrong version

Yep. Weird bug in the release process caused this. We have fixed it and will be releasing 0.120.1 soon.

langri-sha

comment created time in 3 months

issue closedflowtype/flow-bin

Flow server reporting wrong version

After installing flow-bin@0.120.0, the Flow server is wrongly reporting the version v0.191.1:

./flow-linux64-v0.120.0/flow --version
Flow, a static type checker for JavaScript, version 0.119.1

Verification passes:

$ shasum -c SHASUM256.txt
flow-linux64-v0.120.0/flow: OK
flow-osx-v0.120.0/flow: OK
flow-win64-v0.120.0/flow.exe: OK

closed time in 3 months

langri-sha

created tagflowtype/flow-bin

tagv0.120.0

Binary wrapper for Flow - A static type checker for JavaScript

created time in 3 months

push eventflowtype/flow-bin

Daniel Sainati

commit sha 106d82252c09ee027ae6dd30c47d3e4bb89796c1

v0.120.0

view details

push time in 3 months

more