profile
viewpoint
Andy Matuschak andymatuschak San Francisco, CA http://andymatuschak.org Wonder, blunder, salve, solve! Working on tools that expand what people can think and do. Past: led R&D @khanacademy; helped build iOS @apple.

andymatuschak/note-link-janitor 440

Maintains backlink structure among interlinked Markdown notes

andymatuschak/Khan-Academy-Offer-Acceptance-Toy 76

The playful way that I joined Khan Academy.

andymatuschak/Bear-Markdown-Export 60

Markdown export from Bear sqlite database

andymatuschak/DOMNodeAndChildOffsetContainingViewportLocation 7

What is at this location—to the letter?

andymatuschak/66 4

Quartz Composer-based reinterpretation of Tangent Spaces' reinterpretation of Geometry Daily #66

andymatuschak/alfred-bear 4

Alfred 3 workflow to create and search notes in Bear.

andymatuschak/alfred-ulysses-workflow 3

Alfred 3 workflow for Ulysses

andymatuschak/bear-link-janitor 2

A fairly dangerous script which monitors + fixes broken wiki-style links in one's Bear library

andymatuschak/dynamicland-video-dropzone 2

Physical-to-digital-to-physical bridge for video in Dynamicland: video uploading webserver

andymatuschak/articles 1

All current objc.io articles

issue closedandymatuschak/note-link-janitor

Markdown link support

Would it be possible to add standard markdown link support? ()

closed time in 8 hours

NullSense

issue commentandymatuschak/note-link-janitor

Markdown link support

Sorry, no; see README:

This is FYI-style open source. I'm sharing it for interested parties, but without any stewardship commitment. Assume that my default response to issues and pull requests will be to ignore or close them without comment. If you do something interesting with this, though, please let me know.

NullSense

comment created time in 8 hours

issue openedipld/js-dag-json

Update for compatibility with multiformats 4 configuration-free API

https://github.com/multiformats/js-multiformats/pull/36 rewrites the API of multiformats to avoid creating a central registrar object, but this module expects the now-defunct object as an argument to its constructor. This module will need to be rewritten either to import its own dependencies from multiformats or to consume them as arguments.

created time in 25 days

fork andymatuschak/yargs

yargs the modern, pirate-themed successor to optimist.

http://yargs.js.org/

fork in a month

issue commentandymatuschak/note-link-janitor

Error: Missing compiler for node of type `wikiLink`: `[object Object]`

Sorry, I can't offer support for this project.

linxule

comment created time in a month

issue closedandymatuschak/note-link-janitor

Error: Missing compiler for node of type `wikiLink`: `[object Object]`

Thank you for this script!

After run, I see this error message:

(node:20403) UnhandledPromiseRejectionWarning: Error: Missing compiler for node of type wikiLink: [object Object]

Would you be able to help me resolve this? I tried to install remark but the issue persisted

closed time in a month

linxule

issue commentwhatwg/html

should BroadcastChannel be disabled if a window does not have access to storage?

This issue is dormant for the moment, but in case it revives:

Per @othermaciej, it's true that BroadcastChannel can be used as part of a strategy to defeat ITP's partitioning! But a partitioned BroadcastChannel is still useful. I'm using it (in Firefox and Chrome) to communicate between same-origin sibling iframes embedded in a third-party context. This allows me to propagate user state across these embedded interfaces when the user has disabled third-party storage (which also disables sessionStorage in those browsers). This use case would still work fine if BroadcastChannel were partitioned—but not if it were disabled completely in this storage-less context.

wanderview

comment created time in a month

pull request commentandymatuschak/note-link-janitor

Backlink insertion is idempotent

Thanks for submitting a pull request, Aaron. I don't really understand what you're trying to do here. Could you describe in more detail please?

aaronjensen

comment created time in 2 months

issue commentprivacycg/storage-access

Provide mechanism for nested iframes to request storage access

Expanding from the specific use cases described above, there's another general swath of clients which will require nested iframes: OEmbed clients who sandbox arbitrary embedded content (videos, imagery, rich media) via iframes or services like Embed.ly.

Wordpress, Notion, Medium, Reddit, and Confluence allow users to embed YouTube videos, CodePen sandboxes, Instagram posts, and other such content through a service called Embed.ly. This service manually vets OEmbed providers and provides a consistent interface to its clients by wrapping the embedded media in an iframe. But most of these OEmbed providers themselves deliver their content through iframes. So in practice, if you're embedding media like this in any of these popular sites, the content is delivered in a nested iframe: Notion > Embed.ly > Figma.

If the Storage Request API doesn't allow the nested iframe to request access, then it will exclude this very common use case.

bgirardeau

comment created time in 2 months

pull request commentfacebook/react-native

[Catalyst][Text] Fix Catalyst text rendering by disabling inappropriate subpixel-antialiasing

Thank you for testing and landing this!

andymatuschak

comment created time in 2 months

PR opened tradle/asyncstorage-down

Remove iOS-only caveat from mention of react-native-leveldown

This library now includes Android native bindings as well.

+1 -1

0 comment

1 changed file

pr created time in 2 months

push eventandymatuschak/asyncstorage-down

Andy Matuschak

commit sha abb646741812dd255ce1ea708f8946e47370f360

Remove iOS-only caveat from mention of react-native-leveldown

view details

push time in 2 months

pull request commentandymatuschak/react-native-leveldown

Add Android bindings

Done: d07acd1. We're now at 1.0! Thanks again—looking forward to getting Orbit up and running on Android…

RAN3000

comment created time in 2 months

created tagandymatuschak/react-native-leveldown

tagv1.0.0

Native bindings to LevelDB for React Native, exposed as leveldown-compatible interface

created time in 2 months

push eventandymatuschak/react-native-leveldown

Andy Matuschak

commit sha d07acd127186679a51d8e3f1451f16dd4c73e9e1

Updating Readme and NPM package for 1.0

view details

push time in 2 months

push eventandymatuschak/react-native-leveldown

Giacomo Randazzo

commit sha e393f04f5d7b7af5758f38b9f53b3e6f50fb7df3

Add Android bindings

view details

Giacomo Randazzo

commit sha a79a6cc546fd47af3edbd966a33776e377cd4c06

Depend on remote leveldb-android library

view details

Andy Matuschak

commit sha acb9c2e534114a84f1caa1044a22416a94a4efd3

Merge pull request #4 from RAN3000/android Add Android bindings

view details

push time in 2 months

PR merged andymatuschak/react-native-leveldown

Add Android bindings

I've added a React Native Android module, all tests pass. The module relies on my own fork of leveldb-android.

The initial idea was to use android-leveldb by litl but I've found that it lacked some functionalities required by the abstract-leveldown interface. I've found another similar project: leveldb-android by hf. It was more complete but it still lacked support for the errorIfMissing configuration parameter. I forked the library and added the parameter (actually there was an umerged pull request sitting around in the original project with the required feature, I copied the code over to the fork).

Resolves #1

+772 -48

2 comments

14 changed files

RAN3000

pr closed time in 2 months

issue closedandymatuschak/react-native-leveldown

Add Android bindings

Right now, this project only has iOS/Mac bindings. I'd like to add Android bindings, too, but I don't have much experience with the Android build system, so I suspect it'll take me a while.

I'd be grateful for help! Looks like there are already LevelDB JNI bindings we can use.

closed time in 2 months

andymatuschak

pull request commentandymatuschak/react-native-leveldown

Add Android bindings

Hooray! I just ran the Android test suite, and everything looks great.

I'll merge this, then update the Readme, add the Android paths to package.json so it's included in NPM, then publish 1.0.

Thank you so much, @RAN3000!

RAN3000

comment created time in 2 months

Pull request review commentandymatuschak/react-native-leveldown

Add Android bindings

+module.exports = {+  dependencies: {+    'react-native-leveldown': {+      platforms: {+        android: null, // disable Android platform, other platforms will still autolink if provided

Fantastic!!

RAN3000

comment created time in 2 months

Pull request review commentandymatuschak/react-native-leveldown

Add Android bindings

+module.exports = {+  dependencies: {+    'react-native-leveldown': {+      platforms: {+        android: null, // disable Android platform, other platforms will still autolink if provided

Hm, could you help me follow why clients must disable auto linking for this library? Is the idea that this module must be manually linked, rather than auto-linked, because of the leveldb-android dependency?

RAN3000

comment created time in 2 months

Pull request review commentandymatuschak/react-native-leveldown

Add Android bindings

+package com.reactnativeleveldown;++import android.util.Log;++import com.facebook.react.bridge.LifecycleEventListener;+import com.facebook.react.bridge.Promise;+import com.facebook.react.bridge.ReactApplicationContext;+import com.facebook.react.bridge.ReactContextBaseJavaModule;+import com.facebook.react.bridge.ReactMethod;+import com.facebook.react.bridge.ReadableArray;+import com.facebook.react.bridge.ReadableMap;+import com.facebook.react.bridge.WritableArray;+import com.facebook.react.bridge.WritableMap;+import com.facebook.react.bridge.WritableNativeArray;+import com.facebook.react.bridge.WritableNativeMap;+import com.github.hf.leveldb.LevelDB;+import com.github.hf.leveldb.WriteBatch;+import com.github.hf.leveldb.exception.LevelDBException;+import com.github.hf.leveldb.util.Bytes;+import com.github.hf.leveldb.util.SimpleWriteBatch;++import java.io.File;+import java.util.HashMap;+import java.util.Map;++public class LeveldownModule extends ReactContextBaseJavaModule implements LifecycleEventListener {++    private final ReactApplicationContext reactContext;++    public LeveldownModule(ReactApplicationContext reactContext) {+        super(reactContext);+        this.reactContext = reactContext;+        reactContext.addLifecycleEventListener(this);+    }++    @Override+    public String getName() {+        return "Leveldown";+    }++    private static final String TAG = "ReactNativeLeveldown";++    private static final String E_ALREADY_OPEN = "E_ALREADY_OPEN";+    private static final String E_UNKNOWN_HANDLE = "E_UNKNOWN_HANDLE";+    private static final String E_OPEN_ERROR = "E_OPEN_ERROR";+    private static final String E_PUT_ERROR = "E_PUT_ERROR";+    private static final String E_DELETE_ERROR = "E_DELETE_ERROR";+    private static final String E_BATCH_UNKNOWN_OPERATION_TYPE = "E_BATCH_UNKNOWN_OPERATION_TYPE";+    private static final String E_BATCH_OPERATION_ERROR = "E_BATCH_OPERATION_ERROR";+    private static final String E_GET_ERROR = "E_GET_ERROR";+    private static final String E_CLEAR_ERROR = "E_CLEAR_ERROR";+    private static final String E_ITERATOR_CREATE = "E_ITERATOR_CREATE";+    private static final String E_ALREADY_INITIALIZED = "E_ALREADY_INITIALIZED";+    private static final String E_ITERATOR_GET = "E_ITERATOR_GET";+    private static final String E_ITERATOR_SEEK = "E_ITERATOR_SEEK";+    private static final String E_ITERATOR_CLOSE = "E_ITERATOR_SEEK";++    private Map<Integer, LevelDB> dbHandleTable = new HashMap<>();++    private LevelDB getDb(int dbHandle, Promise promise) {+        if (!dbHandleTable.containsKey(dbHandle)) {+            promise.reject(E_UNKNOWN_HANDLE,  String.format("Unknown DB handle %s", dbHandle));+        }+        return dbHandleTable.get(dbHandle);+    }+    private Map<Integer, LeveldownIterator> iteratorWrapperTable = new HashMap<>();++    private LeveldownIterator getIterator(int iteratorHandle, Promise promise) {+        if (!iteratorWrapperTable.containsKey(iteratorHandle)) {+            promise.reject(E_UNKNOWN_HANDLE,  String.format("Unknown iterator handle %s", iteratorHandle));+        }+        return iteratorWrapperTable.get(iteratorHandle);+    }++    @ReactMethod+    public void open(int dbHandle, String databaseName, boolean createIfMissing, boolean errorIfExists, Promise promise) {+        if (dbHandleTable.containsKey(dbHandle)) {+            promise.reject(E_ALREADY_OPEN,  String.format("DB with handle %s already open", dbHandle));+        }++        LevelDB.Configuration configuration = LevelDB.configure().createIfMissing(createIfMissing).exceptionIfExists(errorIfExists);++        try {+            LevelDB db = LevelDB.open(reactContext.getFilesDir().getAbsolutePath() +

Since these databases aren't user-modifiable, would it make more sense to use getDataDir? My understanding is that files in this path would show up elsewhere in the Android interface—e.g. a file browser app. But I don't know what's idiomatic platform-wise here!

RAN3000

comment created time in 2 months

issue commentfacebook/react-native

Pressable has unchangeable delay for opacity effect (onPressIn)

FWIW, sharing how UIKIt handles this: by default, press interactions on buttons are delayed when they're inside of scroll views (and not otherwise). UIScrollView exposes a delaysContentTouches property (default on) which controls this behavior. But of course, you don't really want to hard-couple scroll views and buttons; the mechanism is more general. At the UIGestureRecognizer level, this controls the delaysTouchesBegan property on the scroll view's UIPanGestureRecognizer.

mrousavy

comment created time in 2 months

Pull request review commentinvertase/react-native-firebase

fix(Storage): AL (asset library) methodology deprecated since iOS 8

 + (PHAsset *)fetchAssetForPath:(NSString *)localFilePath {   if ([localFilePath hasPrefix:@"assets-library://"] || [localFilePath hasPrefix:@"ph://"]) {     if ([localFilePath hasPrefix:@"assets-library://"]) {       NSURL *localFile = [[NSURL alloc] initWithString:localFilePath];-#if TARGET_OS_MACCATALYST

Thanks for checking. This'll be fine!

russellwheatley

comment created time in 2 months

push eventandymatuschak/react-native

Andy Matuschak

commit sha eb5ff30d182af0df90237d976ee9c5670910bc44

Disabling font smoothing on Catalyst - Fabric version

view details

push time in 2 months

pull request commentfacebook/react-native

[Catalyst][Text] Fix Catalyst text rendering by disabling inappropriate subpixel-antialiasing

Thanks for that, @sammy-SC! I've just spent a while trying to get Fabric up and running (with iOS in general, not even on Catalyst). I faced immediate configuration issues which suggested to me that master may have some out of date Fabric components: several configuration files contain paths which are clearly wrong, and a dependency on flow-node was introduced without being added to the package.

I was able to make some progress by making the changes:

diff --git a/ReactCommon/react/renderer/graphics/React-graphics.podspec b/ReactCommon/react/renderer/graphics/React-graphics.podspec
index ddd519790e..07d54f808f 100644
--- a/ReactCommon/react/renderer/graphics/React-graphics.podspec
+++ b/ReactCommon/react/renderer/graphics/React-graphics.podspec
@@ -5,7 +5,7 @@
 
 require "json"
 
-package = JSON.parse(File.read(File.join(__dir__, "..", "..", "..", "package.json")))
+package = JSON.parse(File.read(File.join(__dir__, "..", "..", "..", "..", "package.json")))
 version = package['version']
 
 source = { :git => 'https://github.com/facebook/react-native.git' }
diff --git a/package.json b/package.json
index b9d85cdd85..99f3510d0f 100644
--- a/package.json
+++ b/package.json
@@ -142,6 +142,7 @@
     "eslint-plugin-react-native": "3.8.1",
     "eslint-plugin-relay": "1.7.1",
     "flow-bin": "^0.131.0",
+    "flow-remove-types": "^2.131.0",
     "jest": "^26.0.1",
     "jest-junit": "^10.0.0",
     "jscodeshift": "^0.9.0",
diff --git a/scripts/react_native_pods.rb b/scripts/react_native_pods.rb
index 73bb9ad55a..534dd6d298 100644
--- a/scripts/react_native_pods.rb
+++ b/scripts/react_native_pods.rb
@@ -52,7 +52,7 @@ def use_react_native! (options={})
 
   if fabric_enabled
     pod 'React-Fabric', :path => "#{prefix}/ReactCommon"
-    pod 'React-graphics', :path => "#{prefix}/ReactCommon/fabric/graphics"
+    pod 'React-graphics', :path => "#{prefix}/ReactCommon/react/renderer/graphics"
     pod 'React-jsi/Fabric', :path => "#{prefix}/ReactCommon/jsi"
     pod 'React-RCTFabric', :path => "#{prefix}/React"
     pod 'Folly/Fabric', :podspec => "#{prefix}/third-party-podspecs/Folly.podspec"

But even after these patches, the React-graphics pod appears to have some misconfiguration issues. It fails to build with this error:

/Users/andym/Development/External/react-native/ReactCommon/react/renderer/graphics/platform/ios/Color.h:13:10: 'react/renderer/graphics/ColorComponents.h' file not found

… which makes sense, because the Pod's Xcode project is missing most its the source files, including the RCTTextLayoutManager.mm file I've modified:

Screen Shot 2020-08-12 at 9 57 25 AM

At this point, I stopped, because these problems don't appear to be local to my machine—it looks to me more like I'm simply not running known-good sources for Fabric.

I've updated the test plan in the pull request description to include the steps for running RNTester on macOS/Catalyst, and I've pushed a commit to my branch which implements my change for Fabric. If you'd be willing to test the change yourself or to point me to where I've gone wrong in my attempt above, I'd be grateful.

andymatuschak

comment created time in 2 months

issue commentandymatuschak/react-native-leveldown

Add Android bindings

Fantastic—how exciting! High-performance object stores for cross-platform clients: that's a great thing.

andymatuschak

comment created time in 2 months

push eventandymatuschak/react-native

Andy Matuschak

commit sha 0dfe6c2f8fdc4bb57fbf978c9b4f3e3afdaff23a

Switching to more appropriate CGContext save/restore functions

view details

push time in 3 months

pull request commentfacebook/react-native

[Catalyst][Text] Fix Catalyst text rendering by disabling inappropriate subpixel-antialiasing

Changed category to "iOS" from "Catalyst" per @pull-bot.

andymatuschak

comment created time in 3 months

PR opened facebook/react-native

[Catalyst][Text] Fix Catalyst text rendering by disabling inappropriate subpixel-antialiasing

Summary

I noticed when porting my iOS app to macOS via Catalyst that the text rendering was somewhat different on the two platforms. Text looked blurry and over-weight on macOS, even when disabling the Catalyst scaling transform.

I hazily remembered that I'd seen this problem before in my old Cocoa development days: this kind of blurring occurs when rendering text with sub-pixel anti-aliasing into an offscreen buffer which will then be traditionally composited, because when the SPAA algorithm attempts to blend with the underlying content (i.e. in the offscreen buffer), there isn't any. SPAA is disabled on iOS, so the issue wouldn't appear there. On macOS, typical approachs to displaying text (e.g. CATextLayer) normally disable SPAA, since it's been incompatible with the platform's compositing strategy since the transition to layer-backed views some years ago. But React Native uses NSLayoutManager to rasterize text (rather than relying on the system render server via CATextLayer), and that class doesn't touch the context's font smoothing bit before drawing.

This change makes macOS/Catalyst text rendering consistent with iOS text rendering by disabling SPAA.

It appears that the code I've modified is in the process of being refactored (for Fabric?). It looks like this is the corresponding place in the new code (@sammy-SC, is that right?). I'm happy to include a change to the new renderer in this patch if someone can point me at how to test that change.

Changelog

[Catalyst] [Fixed] - Improved text rendering on macOS Catalyst

Test Plan

The difference is seen immediately when running any ReactNative app with text on macOS via Catalyst. See incorrect rendering above, correct rendering below.

Screen Shot 2020-08-10 at 11 40 48 AM Screen Shot 2020-08-10 at 11 39 22 AM

+13 -0

0 comment

1 changed file

pr created time in 3 months

push eventandymatuschak/react-native

Andy Matuschak

commit sha 6fbc17b079967574c5deab67ba2d239d1d741a9a

Fix Catalyst text rendering by disabling inappropriate subpixel-antialiasing

view details

push time in 3 months

issue commentandymatuschak/react-native-leveldown

Add Android bindings

Rad! Thanks so much for giving it a try, @RAN3000!

andymatuschak

comment created time in 3 months

issue commentbulenkov/VSCodeKeymap4IntelliJ

Latest update broke custom configs

I hit this issue this morning when updating, too. I've fixed the issue for myself, but if it's possible to resolve this issue in future updates, I suspect that will avoid many other disrupted mornings!

valtism

comment created time in 3 months

push eventandymatuschak/react-native-leveldown

Andy Matuschak

commit sha 858fe58d9829e947e6a9f38ea4bc997cbc4d2cd5

Update react-native-leveldown.podspec

view details

push time in 3 months

issue closedLevel/abstract-leveldown

Open to adding an optional "batched get" capability?

Many implementations of abstract-leveldown involve FFI, which often incurs transaction overhead. There are good ways to mitigate this overhead for writes and for iterators (the batch API and chunked reads, respectively), but there's no good way to avoid significant FFI overhead when making large numbers of random-access get calls. Existing implementors can batch reads at every tick, but that approach introduces delay for common-case simple reads, as well as extra bookkeeping to track information the client may already have.

How would you all feel about a proposal to make get accept an array of keys? This would be an optional feature, with support indicated by a new supports manifest key (e.g. batchedGet). If there's support for this feature, I'm willing to write a more formal proposal describing its semantics in more detail, implement demonstration support in memdown, and add appropriate tests.

closed time in 3 months

andymatuschak

issue commentLevel/abstract-leveldown

Open to adding an optional "batched get" capability?

Ah, I see! This is a pretty clear dupe of Level/levelup#491 and Level/levelup#13 (sorry I missed those!), so let's go ahead and close this.

And I previously believed (or hoped) that "batch get" could be implemented in userland on top of iterators, but this is difficult to optimize.

Yes, I see how this could be done, but in the case of random-access read, it still requires 2N FFI round-trips per requested key; I'd like a constant-overhead interface.

Having read the discussion and some of the considerations involved, I'll probably go ahead and just implement this in my own library (https://github.com/andymatuschak/react-native-leveldown) and link it in the relevant issues here in case others want to implement a similar API.

andymatuschak

comment created time in 3 months

issue openedLevel/abstract-leveldown

Open to adding an optional "batched get" capability?

Many implementations of abstract-leveldown involve FFI, which often incurs transaction overhead. There are good ways to mitigate this overhead for writes and for iterators (the batch API and chunked reads, respectively), but there's no good way to avoid significant FFI overhead for random-access get calls. Existing implementors can batch reads at every tick, but that approach introduces delay for common-case simple reads, as well as extra bookkeeping to track information the client may already have.

How would you all feel about a proposal to make get accept an array of keys? This would be an optional feature, with support indicated by a new supports manifest key (e.g. ’batchedGet). If there's support for this feature, I'm willing to write a more formal proposal describing its semantics in more detail, implement demonstration support inmemdown`, and add appropriate tests.

created time in 3 months

push eventandymatuschak/react-native-leveldown

dependabot[bot]

commit sha a6c5323b5821e2043f52f29126c915b55dd2e35b

Bump lodash from 4.17.15 to 4.17.19 Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

Andy Matuschak

commit sha d65bb5a2cab6066238fb4abda2466ed02e245188

Merge pull request #2 from andymatuschak/dependabot/npm_and_yarn/lodash-4.17.19 Bump lodash from 4.17.15 to 4.17.19

view details

push time in 3 months

PR merged andymatuschak/react-native-leveldown

Bump lodash from 4.17.15 to 4.17.19 dependencies

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 months

push eventandymatuschak/react-native-leveldown

dependabot[bot]

commit sha 6437811ac0ad55b81681fcbfbe6973e7d6fe4a77

Bump lodash from 4.17.15 to 4.17.19 in /testapp Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

Andy Matuschak

commit sha d556fdca5baab85ce27da497256df89bbeffbbe3

Merge pull request #3 from andymatuschak/dependabot/npm_and_yarn/testapp/lodash-4.17.19 Bump lodash from 4.17.15 to 4.17.19 in /testapp

view details

push time in 3 months

PR merged andymatuschak/react-native-leveldown

Bump lodash from 4.17.15 to 4.17.19 in /testapp dependencies

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 months

push eventandymatuschak/react-native-leveldown

Andy Matuschak

commit sha f61624ca7d9d243a5c075d4524aa5026270a8041

v0.0.6

view details

Andy Matuschak

commit sha 2c948f58c5514fa1f54eef0d1276304e866e69e0

Correctly zeroing stepCount at initialization.

view details

Andy Matuschak

commit sha df3db9f7a47411c59c393b93d3ac12d079b4627d

v0.0.7

view details

push time in 3 months

issue commentfacebook/react-native

Line height is distributed unevenly when lineHeight <= fontSize

@ravirajn22: Nope, that doesn't change the output, neither on Android nor on iOS.

andymatuschak

comment created time in 3 months

issue commentfacebook/react-native

Line height is distributed unevenly when lineHeight <= fontSize

A workaround for readers who stumble on this issue: if you'd like to use smaller line heights without glyph clipping, you'll need to add top padding to the Text element, which you must then compensate for by shifting the element up (e.g. via top plus relative positioning, or a negative marginTop).

andymatuschak

comment created time in 3 months

issue openedfacebook/react-native

Text clips glyphs at smaller line heights

Description

When lineHeight is less than the fontSize, Text shrinks the line's bounding box only by removing space from above the text, rather than distributing the space evenly above and below, as is done with extra line height. Actually, the issue manifests when lineHeight is less than fontSize plus some small amount (perhaps the font bounding box height?)—e.g. <= 45px for 40px Helvetica.

This produces differences in text rendering between react-native-web and react-native (https://github.com/necolas/react-native-web/issues/1687). After some discussion with @necolas, my inclination is that RNW's behavior is the more reasonable one, so I thought I'd open an issue here.

This issue reproduces across a variety of fonts.

image

Unfortunately,I worry that fixing this issue will create subtle and surprising source compatibility issues for existing clients.

React Native version:

Run react-native info in your terminal and copy the results here.

Steps To Reproduce

Run example app here: https://snack.expo.io/W51F2OAqD

Expected Results

The extra line spacing should be removed evenly from both above and below the type.

Snack, code example, screenshot, or link to a repository:

https://snack.expo.io/W51F2OAqD

created time in 3 months

issue commentnecolas/react-native-web

Text metrics do not match React Native at smaller line heights

Got it. I'll file an issue there and reference this one for interested viewers.

I'd be happy to write a documentation PR in the meantime. Is there a place where you're collecting rendering gotchas between r-n-w and r-n? Looking through the docs, I'm not seeing a spot that looks quite right to mention this—perhaps http://necolas.github.io/react-native-web/docs/?path=/docs/guides-style--page?

andymatuschak

comment created time in 3 months

issue openednecolas/react-native-web

Text metrics do not match React Native at smaller line heights

The problem react-native-web's implementation of <Text> positions text differently within the element's bounding box than react-native's implementation of <Text> (running on iOS—haven't checked Android, but I assume/hope it's the same). This issue reproduces across a variety of fonts.

Interestingly, the two implementations appear to render the same when the lineHeight is large enough—e.g. above around a lineHeight of 45px for 40px Helvetica. Perhaps this is the ascender height? The font's bounding box height? I'm not sure. The issue also does not appear to manifest when lineHeight is unset—i.e. with the default lineHeight.

This issue makes it impossible to create a shared web/native implementation which aligns to the same grid.

How to reproduce

This test case displays the issue: https://codesandbox.io/s/affectionate-ishizaka-ylnhx?file=/src/App.js Here's an Expo Snack link to easily view the same test case on device: https://snack.expo.io/W51F2OAqD

This image compares the renderings: image Environment (include versions). Did this work in previous versions?

  • React Native for Web (version): 0.13.3
  • React (version): 16.13.1
  • Browser: Safari 13.1.1, Chrome 84.0.4147.89

Arguably, the r-n-w behavior is more reasonable than the r-n behavior. I don't really care which behavior is chosen (I'll need to add manual offsets specific to each font's metric)—I just care that they're the same! :)

I worry that fixing this issue will create subtle and surprising source compatibility issues for existing r-n-w clients.

created time in 3 months

more