Create a Post
A framework for building native apps with React
autoComplete prop for <TextInput>
TL;DR: Introduce a new prop for `TextInput` component to configure autocomplete/autofill options in a cross-platform fashion. Long Story: iOS already supports some degree of auto completion through the usage of `textContentType` property (and recently added `username` and `password` options). Android Oreo introduced the AutoFill Framework, for secure communication between an app and autofill services (e.g. Password managers). It introduces two new properties for text input elements (TextEdit, Spinner and alikes): `autofillHints` (accepting constants that range from username and password to credit card number) and `importantForAutofill` (in short, turn it on or off). Out-of-the-box, Android Oreo+ already tries to autofill <TextInput> components in React Native apps based on heuristics (on the placeholder text, for example), but there is no way to actually set configuring options. The quick solution would be to just add an `autofillHints` property in React Native TextInput, but that doesn't bond well with the cross-platform nature of the library. Proposal: Adopt HTML's `autocomplete` attribute. HTML's autocomplete spec can be mapped to Android `autofillHints` & `importantForAutofill` and serves as a proper placeholder for autofill/autocomplete in other platforms. References: Android AutoFill Framework documentation: HTML autocomplete attribute spec: Related Feature Request: Related issue / feature request: facebook/react-native#17097
Background timer execution
in progress "I wanted to start a discussion about the timers and an API that exposes the capabilities of the system timers. A couple of things I noticed were that the timers use CADisplayLink on the main thread and also listen to the UIApplication state notifications. To my knowledge this works well for timers that are coupled to the UI (requestAnimationFrame comes to mind, there may be other uses). I'd like to discuss timers that do other work e.g. interact with the event loop or schedule background tasks, and how they co-interact. Event loop timers seem to fall into two categories - those that run at the end of the current loop and those that run right after. This is like process.nextTick and setImmediate. These aren't too hard to implement though there are a couple of gotchas like warning if a process.nextTick handler endlessly schedules itself before blowing the stack. I would also expect both of these timers to run even if the app is inactive or backgrounded (e.g. say you get a network response while the app is backgrounded and schedule some work to run soon after - it should run in the background). Background task timers (setTimeout, setInterval) raise a couple of questions like the semantics of a zero-ms timeout. I would also propose that these run in the background as well to address the use of running code that does not need the app to be foregrounded. And, if the app is backgrounded there is little harm in running UI code anyway -- in cases where it does matter, the timer handler can check the UIApplication state. Background task timers that repeat are also good candidates for energy optimization. One thing that OS X systems do is coalesce timers where possible, partly aided by the programmer providing a tolerance value. If many running apps schedule timers that can overlap within their respective tolerance windows, the system may wake the CPU just once to run all of those tasks together." - @{ide}
Load More