Josh Abernathy

We currently don't do anything with type hints. We should. Note that we'll also need hints for `IBOutlet`, `IBAction`, etc.

Use flexbox terminology

1

We use flexbox for layout but different terminology. We should use the same so it's easy to share existing knowledge and resources. This'll obviously require changes to SwiftBox.

Re-think in light of protocol extensions

3

Now that protocols can have concrete implementations, we should re-visit whether Few can be designed around value types and protocols. :sparkles:

Multithreading?

11

Should we allow component state to be changed from a background thread? Should it do realization, layout, or diffing on a background thread?

Render from the topmost dirty component downward

1

Currently each component re-renders itself when its state changes. This works, but it's less than ideal. Consider a component A which renders a component B. If both update their state...

Something lense-ish would be [really](https://github.com/joshaber/Few/blob/0ed794d7e3c2102466b9621142ce3bd44a2de962/FewDemo/DemoComponent1.swift#L95) [nice](https://github.com/joshaber/Few/blob/0ed794d7e3c2102466b9621142ce3bd44a2de962/FewDemo/DemoComponent1.swift#L110).

Move to a different backend?

1

Sqlite's awesome, LevelDB might be more awesome. :+1: - [Faster than Sqlite](http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html) - Snapshots are a non-persistent version of our immutable databases. - More thread-safety out of the box. -...

We should run `VACUUM`. Probably as part of trimming.

Transactions exist currently in the database, but we don't expose them to users. It could be useful: - Timestamp for changes. - List of changes. Related to #3.

It'd be useful/cool to be able to say, "give me the database from yesterday", etc.