[Packager] Customizable httpServerLocation

[arbesfeld]

Currently assets always are given a file name with the /assets/ prefix. It would be convenient to be able to specify a root location to use in the packager. For example, using ~/<build_id> would let us package a JavaScript bundle to use assets that live elsewhere on the file system.

Our use case is to allow assets to be dynamically loaded. Currently this is the hack that we're using: https://github.com/AppHubPlatform/apphub-ios/blob/support-new-asset-system/AppHub/AppHub/NSURLRequest%2BAppHub.m

cc @frantic

[frantic]

Hey @arbesfeld, as of 0.14rc, assets are either

• served from packager in when developing locally
• packaged into the app

The code that decides which one to use lives here, however it's an implementation detail and it might change (for example if we switch to Xcode's asset catalogs instead).

If I understand correctly, AppHub will download images and put it somewhere on device, and you'd like to make resolution mechanism to be more configurable to be able to load those images instead of pre-bundled ones?

[arbesfeld]

Hey @frantic, yep exactly. Ideally we would like to tell the image loader mechanism where to load images at run time (this is what the swizzle that I linked does). If this is not supported explicitly by RN, then we would like to be able to configure the packager to create a JSBundle which references assets stored on the file system.

I think this line: https://github.com/facebook/react-native/blob/master/packager/react-packager/src/Bundler/index.js#L298 is where the /assets path is hard coded into the bundler. If we could change this prefix that would allow us to create a JS bundle that refers to external assets.

[frantic]

I'd rather have a way to configure it from the native side. JS code shouldn't be concerned at all about where the images is actually coming from. Also it will be simpler, because you don't have to regenerate bundles for specific use cases (e.g. whenever app is using AppHub or not).

@nicklockwood any ideas how we can make image loading subsystem more customizable?

[arbesfeld]

Also would like to bring @mkonicek into the discussion here for the Android side (realize you're already occupied with my other patch :))

Right now we have to transform our user's Android JS bundles to reference file:// assets, but it would be nice to have the asset loading mechanism be customizable at run time.

[nicklockwood]

I'm not sure I understand the problem. Is it that you want to be able to globally configure where a relative image path is relative to, so that you can switch the location of the assets folder without changing the JS?

[mkonicek]

On Android, image paths are transformed by the packager to a flat hierarchy when bundling the APK and stored in the res/drawable folder in the APK. (The flat hierarchy is a requirement as Android doesn't support subfolders in res/drawable.)

The loading from /drawable is in ReactImageView.

@arbesfeld Do I understand it correctly that you want to customize ReactImageView to load images from somewhere in the file system?

cc @foghina

[arbesfeld]

@nicklockwood @mkonicek Yep, exactly. We'd like to customize where assets are loaded from without having to change the compiled JS.

Any hooks that would let us modify getPathInArchive (either that one method or the whole file) at runtime would probably suffice for this use case.

[nicklockwood]

Another option might be to invent a new URL scheme like "image://" to use for all your images, and then substitute that with "file://someRootPath/", either on the native or JS side.

On the native side you could do it by creating a custom RCTURLRequestHandler module for that scheme. On the JS side you'd probably need to modify resolveAssetSource.js.

[mkonicek]

I think getPathInArchive returns a string like "assets_awesomemodule_icon" and that gets passed to native. Wouldn't it be sufficient to customize the native side to make it load all images from a known folder instead of the Android resources (res/drawable)?

[mkonicek]

Or can you simply replace the Android resources (res/drawable) at runtime?

[arbesfeld]

@nicklockwood I'm not sure I understand. The overall hope is that our users can use images normally: <Image source={require('./foo.png')} /> but have this evaluate at runtime to file://someRootPath/foo.png where someRootPath might change between different executions of the app (after updates).

@mkonicek Would certainly work if we could customize the native side (ReactImageView) -- though if there was a hook in JS we could maybe find a solution that works on both iOS and Android? Currently ReactImageView does in fact work with file:// urls.

As far as I know, it's not possible to replace Android resources at runtime.

[frantic]

@nicklockwood good to know about RCTURLRequestHandler! Seems like on iOS we can change uri returned by resolveAssetSource to image://... and have a custom handler that would know how to deal with that (by default load from app's bundle). The question is – can third party library override existing bridge module (with the one that would handle image:// differently and allow loading from different location)?

@mkonicek regarding Android I talked to @natthu and he mentioned that Fresco should be able to load images from files instead of using Android's resource manager.

[frantic]

also cc @zahanm

[nicklockwood]

Yes, you can create new handlers for existing protocols and assign them a higher priority.