Fix website

Summary:This puts the images inside of the blog folder in the output so we can safely copy them over. And moves the images in /blog/img/ in the source control so it's easier to discover (instead of having to search many levels deep).

Should make the website work!
Closes https://github.com/facebook/react-native/pull/6659

Differential Revision: D3098308

Pulled By: vjeux

fb-gh-sync-id: 99477e27843dd6c88aa854028944f2f0b672db1f
fbshipit-source-id: 99477e27843dd6c88aa854028944f2f0b672db1f
This commit is contained in:
Christopher Chedeau 2016-03-25 10:45:24 -07:00 committed by Facebook Github Bot 3
parent e54876dbd0
commit 51e013633c
9 changed files with 14 additions and 22 deletions

View File

@ -20,7 +20,7 @@ The idea behind hot reloading is to keep the app running and to inject new versi
A video is worth a thousand words. Check out the difference between Live Reload (current) and Hot Reload (new).
<iframe width="650" height="315" src="https://www.youtube.com/embed/2uQzVi-KFuc" frameborder="0" allowfullscreen></iframe>
<iframe width="100%" height="315" src="https://www.youtube.com/embed/2uQzVi-KFuc" frameborder="0" allowfullscreen></iframe>
If you look closely, you can notice that it is possible to recover from a red box and you can also start importing modules that were not previously there without having to do a full reload.
@ -40,7 +40,7 @@ Hot Reloading is built on top of a feature [Hot Module Replacement](https://webp
In a nutshell, the HMR update contains the new code of the JS modules that changed. When the runtime receives them, it replaces the old modules' code with the new one:
![](/react-native/img/blog/hmr-architecture.png)
![](/react-native/blog/img/hmr-architecture.png)
The HMR update contains a bit more than just the module's code we want to change because replacing it, it's not enough for the runtime to pick up the changes. The problem is that the module system may have already cached the *exports* of the module we want to update. For instance, say you have an app composed by these two modules:
@ -66,7 +66,7 @@ module.exports = time;
The module `log`, prints out the provided message including the current date provided by the module `time`.
When the app is bundled, React Native registers each module on the module system using the `__d` function. For this app, among many `__d` definitions, there will one for `foo`:
When the app is bundled, React Native registers each module on the module system using the `__d` function. For this app, among many `__d` definitions, there will one for `log`:
```
__d('log', function() {
@ -90,7 +90,7 @@ module.exports = bar;
The Packager will send time's new code to the runtime (step 1), and when `log` gets eventually required the exported function gets executed it will do so with `time`'s changes (step 2):
![](/react-native/img/blog/hmr-step.png)
![](/react-native/blog/img/hmr-step.png)
Now say the code of `log` requires `time` as a top level require:
@ -110,7 +110,7 @@ When `log` is required, the runtime will cache its exports and `time`'s one. (st
For `log` to pick up `time` changes, we'll need to clear its cached exports because one of the modules it depends on was hot swapped (step 3). Finally, when `log` gets required again, its factory function will get executed requiring `time` and getting its new code.
![](/react-native/img/blog/hmr-log.png)
![](/react-native/blog/img/hmr-log.png)
## HMR API
@ -137,7 +137,7 @@ Note that only in rare cases you would need to use this API manually. Hot Reload
As we've seen before, sometimes it's not enough only accepting the HMR update because a module that uses the one being hot swapped may have been already executed and its imports cached. For instance, suppose the dependency tree for the movies app example had a top-level `MovieRouter` that depended on the `MovieSearch` and `MovieScreen` views, which depended on the `log` and `time` modules from the previous examples:
![](/react-native/img/blog/hmr-diamond.png)
![](/react-native/blog/img/hmr-diamond.png)
If the user access the movies' search view but not the other one, all the modules but `MovieScreen` would have cached exports. If a change is made to module `time`, the runtime will have to clear the exports of `log` for it to pick up `time`'s changes. The process wouldn't finish there: the runtime will repeat this process recursively up until all the parents have been accepted. So, it'll grab the modules that depend on `log` and try to accept them. For `MovieScreen` it can bail, as it hasn't been required yet. For `MovieSearch`, it will have to clear its exports and process its parents recursively. Finally, it will do the same thing for `MovieRouter` and finish there as no modules depends on it.
@ -166,7 +166,7 @@ In order to walk the dependency tree, the runtime receives the inverse dependenc
React components are a bit harder to get to work with Hot Reloading. The problem is that we can't simply replace the old code with the new one as we'd loose the component's state. For React web applications, [Dan Abramov](https://twitter.com/dan_abramov) implemented a babel [transform](http://gaearon.github.io/react-hot-loader/) that uses Webpack's HMR API to solve this issue. In a nutshell, his solution works by creating a proxy for every single React component on *transform time*. The proxies hold the component's state and delegate the lifecycle methods to the actual components, which are the ones we hot reload:
![](/react-native/img/blog/hmr-proxy.png)
![](/react-native/blog/img/hmr-proxy.png)
Besides creating the proxy component, the transform also defines the `accept` function with a piece of code to force React to re-render the component. This way, we can hot reload rendering code without losing any of the app's state.

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

BIN
blog/img/hmr-log.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

View File

Before

Width:  |  Height:  |  Size: 8.5 KiB

After

Width:  |  Height:  |  Size: 8.5 KiB

View File

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 21 KiB

File diff suppressed because one or more lines are too long

View File

@ -95,6 +95,12 @@ function execute() {
glob.sync('src/react-native/docs/*.*').forEach(rmFile);
glob.sync('src/react-native/blog/*.*').forEach(rmFile);
glob.sync('../blog/img/*.*').forEach(file => {
writeFileAndCreateFolder(
'src/react-native/blog/img/' + path.basename(file),
fs.readFileSync(file)
);
});
var metadatas = {
files: [],
@ -167,7 +173,7 @@ function execute() {
);
files = glob.sync(BLOG_MD_DIR + '**/*.*');
files = glob.sync(BLOG_MD_DIR + '**/*.md');
const metadatasBlog = {
files: [],
};

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB