Component ratio support

There are several places where we can optimize to make Jasonette scroll smoothly.

One of those cases is handling component dimension. To understand why this is so, I need to discuss how this is implemented internally. You can skip this part and jump to the next "proposal" section if you're just curious about the proposed solution.

# 1. How app layout works

## How Jasonette handles layout

All mobile devices implement some sort of "autolayout" features (both iOS and Android). This makes sure components **without** a dimension attribute will be automatically resized to "just work".

But sometimes the autolayout feature gets confused how exactly to lay them out. This is especially the case when you're loading an image. If you don't set the width and height directly on the image, Jasonette will try to figure it out AFTER the image has loaded by looking at the image file itself.

This normally does a good job but in some cases this resolution is visible and that's what makes it feel "jerky" when scrolling. Currently you can get around this if you use fixed width and height (must set **both width and height**)

## How most native apps handle layout

Also note that this is not a "native vs. non-native" problem. Just take a look at a google search page for https://www.google.com/search?q=ios+scroll+jerky&oq=ios+scroll+&aqs=chrome.0.69i59j69i57j0l4.16386j0j7&sourceid=chrome&ie=UTF-8#q=ios+scroll+stutter This is a very common problem even among native ios developers.

And this is why a lot of apps have uniform components (Instagram used to only allow square images and many apps have fixed media sizes just to not worry about all the complexity that arise by allowing variable component sizes).

And even the apps that **do** have variable component sizes have to work hard to implement custom optimization logic for their apps. While difficult this is possible if you have a specific business logic because you can build your optimization logic around this assumption.

But the goal of Jasonette is to try to come up with a reusable approach to handling these things, so the optimization needs to be universal and shouldn't depend on a specific business logic.

# 2. Proposal

We can get around a lot of layout performance issues by:

1. having a uniform component size
2. setting the width and height manually

But in many cases we want to have variable sized components AND make it work. Like I mentioned in the previous section, this is not an easy task and there is no silver bullet approach to solving this in one fell swoop, so I think the best approach is to keep improving the most obvious use cases.

One such case is components where we know:

1. at least either the width or the height
2. the ratio of width vs. height

Here are some examples:

An image with width of `30%` and height that's twice the size of the width:

```
{
"type": "image",
"url": "http://...",
"style": {
"width": "30%",
"ratio": "2"
}
}
```

An image with width of `100` and height that's half the size of the width:

```
{
"type": "image",
"url": "http://...",
"style": {
"width": "100",
"ratio": "0.5"
}
}
```

Because of the way components are implemented I think we can apply this not just to images but all components, which would improve the performance for this specific case.

If you have better ideas about the JSON syntax, or any other ideas, feel free to share.

The issue does not name implementation files, tests, or an entry point. Start by locating Jasonette's component layout and dimension-handling code, then determine how a ratio style would apply across components; done means a settled JSON syntax and an agreed implementation and test plan for deriving the missing dimension.

Written by the indexing model from the issue text.