An f2 manifest is an endpoint where F2 apps can be retrieved. It consists of a URL,
a friendly name, and a collection of apps. For more information on manifests, visit the
OpenF2 documentation on app development
Loading an app is simple, just click on the app you want to load in the left rail. Fill in the dialogue
box that displays, and click loadapp. If a SampleContext or a DefaultContext was provided to the manifest,
it should auto-populate the app context with those, sample taking priority. It will default to an empty json
object otherwise. Modify the context to change the inputs to the app. As changes are made it will validate
the json, alerting you if there is a problem. Apps can be edited once loaded into the sandbox.
The state of the sandbox is saved after every change. The sandbox state will be restored upon reload
of the development center.
F2 apps and containers talk to each other through custom events. The events are emitted and listened for
the apps and containers. The development center provides a simple interface for testing the use
of events across apps. This is done by hijacking the F2.Events methods.
As an app or container adds and event listener it is added to the list of event listeners in the
Events tab of the development center. A list of event listeners allows for a quick accounting of
all events being watched by all apps loaded into the sandbox.
Every emit is also tracked by the development center. The event is listed in the events tab under
history. Clicking a past event will populate the "emit" section to allow for inspection of the
arguments provided or for refiring the event.
Because all interactions between apps is done through F2.Events, it is useful to be able to emit those
events manually to test those interactions. The emit section will allow you to fire a custom event
with an array of inputs or refire a past event when selected from the history.
A necessary feature of the development center is a persistent state of the sandbox and the ability
reload or share app configurations. Every change to an app in the sandbox will result in a state
save into the browser's localStorage. This sate will be the new default on reload of the page. This
allows for quickly reloading the page to see changes in apps without losing the configuration.
Multiple configurations can be saved to localStorage by clicking the save button ()
below the tabs. This will prompt for a name and save the configuration with that name in localStorage.
Once a configuration is saved a dropdown will appear below the button group. To delete a saved configuration,
select it from the dropdown and click the delete link that gets created.
The use of localStorage means the persistent state and saved configurations will not be shared between
browsers or environments. They will also be lost if browser data is deleted.
A configuration can be saved to disk by clicking the download button ().
This will generate a .json file that contains the json serialized version of the configuration. This
configuration can be shared with other members of your team to quickly load in a collection of apps.
Simply email your colleague the file or send them the file contents.
Loading in a configuration file is as simple as dragging and dropping
the file into the development center.
All apps can be removed from the sandbox by clicking the clear button () in the button group.
This will clear out the current state of the apps.
A key idea behind the development center is to provide a pure location to load in apps and test their
display and functionality. For that reason the sandbox is loaded into an iframe with a bare minimum of
manifest, will be posted to the iframe and subsequently loaded onto the page. There should be little
to no affect on the apps themselves from the sandbox.
Each app loaded into the sandbox is placed inside of a panel. The panel has a few UI elements to make
managing the apps simpler.
Click the refresh button () to reload the specific app. This will remove the
app and readd it in the same location. This is an effective way to test code changes on the app's backend.
F2 loads front end resourcesin those resources.
An existing app can be edited by clicking the edit button (). This allows you to modify the app context or
the dimensions of the app's root. Modifying the context prevents having to remove and readd the app.
Modifying the dimensions of the app root allows for testing the app's dynamism. For testing responsiveness,
changing the size page itself with a collapsed left rail works.
Remove an app from the sandbox by clicking the close button ()
on the app root. This effectively calls F2.removeApp().