-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Migrate to typescript #95
Conversation
And of course the eslint/prettier configurations should be changed. |
I just changed the Eslint configuration but I had to change A LOT of code that may break old code so I guess the best way to do this is to agree on what to do with this migration: should we release a minor release and then a new major release with the linted and clean code (that may break some old false types) ? |
|
(I can say philosophically just in my opinion I think a major is probably warranted, the goal was just for it to be easiest possible migration for any module users, as a general courtesy - I'm guessing it's probably walking that fine line well just based on how you're describing it though I admit I haven't looked) |
I was considering picking up this task together with upgrading Facebook SDK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are few questions of mine also inside some points, specially this name: string | undefined
as I believe we should stick to a pattern in this case using name?: string
as in most cases would have similar effect.
Once again thanks for this PR o/
src/FBAppEventsLogger.ts
Outdated
@@ -131,7 +133,7 @@ module.exports = { | |||
logEvent(eventName: string, ...args: Array<number | Params>) { | |||
let valueToSum = 0; | |||
if (typeof args[0] === 'number') { | |||
valueToSum = args.shift(); | |||
valueToSum = args.shift() as number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead of using ’as’ here, you could use ’Number(args.shift()’
What do you think?
src/FBGraphRequestManager.ts
Outdated
// TODO: [TS Migration]: Added default value to fix type definitions. Discuss before merging. | ||
this.batchCallback = () => {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the case here to just use this.batchCallback?.()
and then you won't need to put a default value here?
But either way having a default noop here seems fine to me.
src/FBLoginButton.tsx
Outdated
DefaultAudience, | ||
LoginBehaviorAndroid, | ||
LoginResult, | ||
LoginTracking, | ||
} from './FBLoginManager'; | ||
|
||
type Event = Object; | ||
type TooltipBehaviorIOS = 'auto' | 'force_display' | 'disable'; | ||
export type Event = any; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we be a bit more strict here?
src/FBProfile.ts
Outdated
@@ -73,17 +70,18 @@ class FBProfile { | |||
this.linkURL = profileMap.linkURL; | |||
this.imageURL = profileMap.imageURL; | |||
this.userID = profileMap.userID; | |||
this.email = Platform.OS === 'android' ? null : profileMap.email; | |||
// TODO: [TS Migration]: Value should be undefined. Discuss before merging. | |||
this.email = Platform.OS === 'android' ? null as unknown as undefined : profileMap.email; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case we could just mark email: string? | null
and we can avoid this unknown type
@thebergamo I'll finalize this on Saturday and I'll be sure to specify all breaking changes and tag you to discuss before merging. Thank you for the collaboration invitation, I'm very excited to help 😄 |
@g-dimitry i guess you would need to rebase as some new feature is added :) |
@thebergamo Unfortunately yes, Sorry for being late, Fell horribly ill. I guess I'll merge master into my branch it would be easier as I have 18 commits which will be a nightmare to rebase. |
That's ok mate, your health is much more important o/ get great recovery 😃 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Just saw this before making the new implementation, does this need help? Maybe I can help complete this before implementing the new feature. |
@mike this one really needs help - yes! It would be fantastic to have this be in typescript and I don't believe the library has moved on that far since it was initially begun here |
okay let me take a look at it |
Commits in this pr have been merged in #160, thanks for all the works. |
Hello Guys,
I've successfully migrated all the code base to Typescript. My philosophy was to try as much as I can to make this a minor release (as @mikehardy stated). You'll see I have added three TODO comments (search for "TODO: [TS Migration]:"). Those are changes that need to be discussed and addressed maybe in the next major release.
To test the compatibility of both the new types and the old types:
import * as oldTypes from 'react-native-fbsdk-next'
andimport * as newTypes from './src'
const o: typeof oldTypes = newTypes;
I guess we need to test it on a running project first to check it works with a JS project & a TS project in development and release modes.
If anybody can test the above and confirm it's not breaking it would be awesome.
Looking forward to your comments.