Add necessary mocks to build Next.js app
#2873
Conversation
m-bert
changed the title
Next.js appNext.js app
| hitSlop?: Insets | undefined; | ||
| } | ||
|
|
||
| export default React.forwardRef<View, { rippleColor: any }>( |
There was a problem hiding this comment.
Shouldn't rippleColor be moved to RawButtonWebProps?
There was a problem hiding this comment.
If only it was so simple 😞 I've spent a lot of time racking my brain to get rid of this TS error and that was the only solution I've come up with. Well, maybe not the only one, but the other was to add {rippleColor: any} into createNativeWrapper:
const ComponentWrapper = React.forwardRef<
React.ComponentType<any>,
P & NativeViewGestureHandlerProps & {rippleColor: any}
>((props, ref) => {which I really don't like
There was a problem hiding this comment.
I don't have any problem with this:
import * as React from 'react';
import { Insets, View } from '../ReactCompat';
import { RawButtonProps } from './GestureButtons';
interface RawButtonWebProps extends RawButtonProps {
hitSlop?: Insets | undefined;
rippleColor?: string | undefined;
}
export default React.forwardRef<View, RawButtonWebProps>(
(props: RawButtonWebProps, ref) => (
<View ref={ref} accessibilityRole="button" {...props} />
)
);Where should I look for the error?
There was a problem hiding this comment.
Well, I do 😞 Here's what I get:
This happens when I try to build Next app, doing lint check and tsc --noEmit in root gives no errors.
There was a problem hiding this comment.
@m-bert If it's not urgent, let's find an opportunity to work on this offline.
There was a problem hiding this comment.
@tjzel It is not. Moreover, we already reverted one of the PRs that was a part of this whole process, so I think it will be the best to start with a discussion about what we want to achieve and which direction should we take.
There was a problem hiding this comment.
MMMMMMMMMMMMMMMMMMMMMMMWNXKKKKKKKKKKXWMMMMMMMMMMMMMMMWWWWMMMMMMM
MMMMMMMMMMMMMMMWX0XWWNXK00KXXXNXXXX0OOKNNWWMMMMMMMMMN0kOKNMMMMMM
MMWXXWMMMMMMMW0dllkKK0OO0KKXXXXXXKK0OO0KKKXXNWMMMMMMW0dxKWMMMMMM
MW0loXMMMMMMWXOxk0KXXKOOOO00000KKKKKKKXXXXKKKKXNNMMMMWKXWMMMMMMM
W0c;oKMMMMMNK0KXXXK00OxdddxkkOOO000KKKXKK0KXXXXK0XWMMMMMMMMMMMMM
Xl',l0WWWWNKO00KK00Okxl::codkkOOOOOO0000OkO0KKK0OOKNWWMMMMMMMMMM
0;..'l0XXXKKKK0OkkOOkkoccdk0KXXKKK0OkkkOOkkkkkO0KKXKXXXNWMMMMMMM
NkoddxOKXXXNNXK00KKXXK0kk0XXXXXXXXK0kkOKXXXK000KXXXNXXK0KNMMMMMM
MMMNOkO0KKXXXKOO0KXXXK0OO0KKKKKKKK0OkxOKK00K00OOKXXXKK0Ok0WMMMMM
MMMXxdxkOOOOOkddkOO0OOxddxkOOOOOOOkxdodkxdxkkkxxxkOOOOkxod0NWMMM
MMMNxcloodddol::clooolc::cllooddoool:;:cloxkkkxdoldddooc:ldONMMM
MMMMKo;;;;;;;,,'',,,,,'''',,;;;;;;,,''',:ldxxddlc;;:;;;,:odxKMMM
WX00KKkl;,''''''''..'''''...........''',:cloolc:,''...';lood0WMM
Nd:ldONWXOxl;'''''.';cc,................',;cc:;,......,::clkNMMM
MKl:lxKMMMMWXOdlc;';kXk;..................,lxkxl'...',;;;:xNMMMM
MMKl:d0KXWMMMMWK0OkO0xc,,,,,;,,,,,,,;;,;;;l0WMWOol:;,;cxOKNMMMMM
MMM0l:;;ckXWMMMMMMMMXxl:,..............,:lONMMMMWWNK00XWMMMMMMMM
MMMMNXx,';lKWMMMMMMNXKKKx' .okk0KKNWWMMMMMMMMMMMMMMMM
MMMMMMWOodONMWXOOOOo::col:;;;,'...',,,:c:;;;;cox0XWWWMMMMMMMMMMM
MMMMMMMMWXK0Okl;;c:'..'',,,,,;cc:::cllllc:;;,'',:dxkXMMMMMMMMMMM
MMMMMMMW0ol:;''';c:,.',,,,,;;:cllcclllccc::ccc:::lo0WMMMMMMMMMMM
MMMMMMMMNOo:;,..'''..',,,''.',:llllllcccccllc::::lOWMMMMMMMMMMMM
MMMMMMMMMWXx:'......',;;;,,,'.':clooollllolc:cc:cxNMMMMMMMMMMMMM
MMMMMMMMMMMW0c......';;;;;;;;'.';:looooooolcclccckWMMMMMMMMMMMMM
MMMMMMMMMMWXkc......',,,,''',;'.';cloooooolc::cclOWMMMMMMMMMMMMM
MMMMMMMMMNkc'........'',.. .::,..,:cllooool;,:c:oKMMMMMMMMMMMMMM
MMMMMMMN0l;,'........',;. ......';:clloool'..,:dXMMMMMMMMMMMMMM
MMMMMMNk:;;,'.......',;:, ....'',;:ccllll;..,co0WMMMMMMMMMMMMM
MMMMMWKo;;;,'......',,;::,....''''',;:cclllc;;cllxXWMMMMMMMMMMMM
MMMMNkl;;,,'......',,;;::;;,,,''''',;;:cccccccclllxXMMMMMMMMMMMM
MMMNOo:,'''.......'',;;;;;;,,,'''''',;;:::cccccccllOWMMMMMMMMMMM
MMMMWNk;'''........',,,,,,,,''''''''',;;;;::cccccccdXMMMMMMMMMMM
MMMMMNd'''.........'',,,,,''.........',;;:clllllllcl0MMMMMMMMMMM
MMMMM0:'''..........'''','...........';:cccccccccccl0MWNMMMMMMMM
MMMMWx,'''............';o:..........';;;;:::c:c:::coKN0KWMWNWMMM
MMMMXo'''......;,.....'lkl.........',,'..,;::::,.';cxkkKWNOONMMM
MMMMNd;,'.....;dc... .lOk:'......',,....';;::;...':okkxkxdONMMM
MMMMWNK0c....'lkd,.. .;d00Oo,....,;'. .';:::cc,..,cdxoclokXWMMM
MMMMMMMWk,...,lxOxc;;,;;;:ldd:....'::,';cccccllc::cloooodkXWMMMM
MMMMMMMMXl...':ok0XXKK0Oc...'......,:ccccccccclllccoddxOKWMMMMMM
MMMMMMMMMKkko,.;cdk000ko;'..',,,,,'',,;::::cccccoxO0KXNWMMMMMMMM
MMMMMMMMMMMMNx,..',;c:,..''.',;;;;,,,,,;,,,;,,:dKWMMMMMMMMMMMMMM
MMMMMMMMMMMMMNx;,::,',,'..'''',;;;;;;;;;'.''':xXMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMWXKNNKo;,;;,''',;;;;;;;,,';:;,cONMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMWXKKkl;,,,:ccccc:::cc:;l0WMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMN0o:,,,,,,;;,,,,:xXMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMW0d:,,,'''',:d0WMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMW0o:,.'',ckNMMMMMMMMMMMMMMMMMMMMMMM
src/handlers/createHandler.tsx
Outdated
| ( | ||
| RNGestureHandlerModule.attachGestureHandler as AttachGestureHandlerWeb | ||
| )( | ||
| (RNGestureHandlerModule as any).attachGestureHandlerWeb( |
There was a problem hiding this comment.
I'd love to avoid casting to any if possible. It will give no feedback in case the internal API changes.
There was a problem hiding this comment.
In that case I believe it will be the best to add ts-ignore. The problem here is that type of Gesture Handler Module comes from Spec which extends TurboModule and I don't want to change native implementation.
There was a problem hiding this comment.
ts-ignore doesn't change much, since it will ignore any errors anyway. While we will likely catch any errors coming from changing module APIs, it would be great to see them immediately in types.
Previous approach, while not looking very nice, was accomplishing this at the cost of duplicating a type. Do we need to rely on the types from Spec on web?
There was a problem hiding this comment.
What do you think about this approach?
There was a problem hiding this comment.
That's better, but I'd like to avoid duplicating the definitions if possible. Have you tried adding the 4th optional argument to the attachGestureHandler? It should make it work without casting but I'm not sure how will it play with codegen.
You'd likely need to make some tricks to make both TS and codegen happy at the same time, but this should work:
type UnsafeMixed = unknown;
...
attachGestureHandler: (
handlerTag: number,
newView: number,
actionType: number,
propsRef?: UnsafeMixed
) => void;
...You would need to also make sure the native code still works, and likely update the generated specs we're using on the old arch.
) ## Description This reverts commit e3e0b79. #2835 was the first PR that was meant to introduce compatibility with `Next.js`. Unfortunately, it broke types outside of our repository. Our `tsconfig.json` has special flag, i.e. `moduleSuffixes`, which allows `tsc` to look for `.native` files first. Most of our users do not have this flag and they've run into `ts` problems, like this one: ``` 'TextInput' refers to a value, but is being used as a type here. Did you mean 'typeof TextInput'? ``` Given that removing `moduleSuffixes` from `tsconfig` results in a bunch of errors (and there are more of them that we may not be aware of), we decided that it will be better to revert this change for now. It is not necessary since we only need it to support `Next.js`. At first I thought that #2873 may help, but unfortunately it doesn't. Fixes #2889 ## Test plan 1. Check that web, Android and iOS work as they did before 2. Check that code from [this comment](#2835 (comment)) now does not throw any errors
Description
This PR adds necessary typescript changes in order to build
Next.jsapp.Test plan
I've tested this changes on branch with Next Example using
yarn build.