import { useEffect, useRef } from 'react'; | |
export const useEventEmitter = (eventEmitter, eventName: string, fn: () => void) => { | |
const subscription = useRef(null); | |
useEffect(() => { | |
subscription.current = eventEmitter.addListener(eventName, fn); | |
return () => { | |
if (subscription.current) { |
- Change React and React Native version on
package.json
- run
yarn install
to upgrade dependencies - run
yarn outdated
oryarn upgrade-interactive
libraries that are outdated (make sure that there's no breaking changes, check release notes (one by one)) - check the diff or use the upgrade-helper and update the native code
- open Xcode and link the binaries
- run on iOS
- test iOS
- run on Android
- test Android
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
module.exports = { | |
presets: [ | |
'@babel/preset-react', | |
[ | |
'@babel/preset-env', | |
{ | |
targets: { | |
node: 'current', | |
}, | |
}, |
The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.
- Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
- Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
- Once documentation has been written, development should commence, and test-driven development is preferred.
- Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
- When a feature is being modified, it should be modified documentation-first.
- When documentation is modified, so should be the tests.
Messaging acronyms are everywhere now. Do you know all of them?
Build a REST API for the World Texting Foundation, also known as WTF.
A sample JSON data file will be provided with a base set of acronym definitions. We expect you to create a NodeJS server using modern best practices for API development. Please consider the recommendations attached as this will list the items we are looking for above.
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
export default async function tryCatch<Data>( | |
promise: Promise<Data>, | |
): Promise<{ error: Error } | { data: Data }> { | |
try { | |
return { data: await promise }; | |
} catch (error) { | |
return { error }; | |
} | |
} |