microsoft
/
react-native-macos
зеркало из https://github.com/microsoft/react-native-macos.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
react-native-macos/Libraries/ReactNative/HeadlessJsTaskError.js

12 строки
284 B
JavaScript
Исходник Обычный вид История

Allow headless JS tasks to retry (#23231) Summary: `setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`. This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion. This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`. Documentation also updated here: https://github.com/facebook/react-native-website/pull/771 ### AppRegistry.js If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself. ### HeadlessJsTaskSupportModule.java Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up. ### HeadlessJsTaskContext.java Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one. ## Changelog [Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay Pull Request resolved: https://github.com/facebook/react-native/pull/23231 Differential Revision: D15646870 fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
2019-06-06 21:54:08 +03:00
/**
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
Convert easy files to flow strict-local Summary: This diff was generated by this script used by WWW https://our.intern.facebook.com/intern/diffusion/WWW/browse/master/scripts/flow/upgrade_to_flow_strict_local.sh?lines=0 Changelog: [Internal] Upgrade flow to flow strict-local Reviewed By: zackargyle, rickhanlonii Differential Revision: D18833630 fbshipit-source-id: e64d4e9a49a0db5e6bf70a0c489567862b578d7f
2019-12-06 02:58:55 +03:00
* @flow strict-local
Allow headless JS tasks to retry (#23231) Summary: `setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`. This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion. This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`. Documentation also updated here: https://github.com/facebook/react-native-website/pull/771 ### AppRegistry.js If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself. ### HeadlessJsTaskSupportModule.java Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up. ### HeadlessJsTaskContext.java Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one. ## Changelog [Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay Pull Request resolved: https://github.com/facebook/react-native/pull/23231 Differential Revision: D15646870 fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
2019-06-06 21:54:08 +03:00
* @format
*/
Tidy up license headers [2/n] Summary: Changelog: [General] [Fixed] - License header cleanup Reviewed By: yungsters Differential Revision: D17952694 fbshipit-source-id: 17c87de7ebb271fa2ac8d00af72a4d1addef8bd0
2019-10-16 20:03:47 +03:00
Allow headless JS tasks to retry (#23231) Summary: `setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`. This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion. This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`. Documentation also updated here: https://github.com/facebook/react-native-website/pull/771 ### AppRegistry.js If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself. ### HeadlessJsTaskSupportModule.java Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up. ### HeadlessJsTaskContext.java Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one. ## Changelog [Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay Pull Request resolved: https://github.com/facebook/react-native/pull/23231 Differential Revision: D15646870 fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
2019-06-06 21:54:08 +03:00
export default class HeadlessJsTaskError extends Error {}