When you start making modular prototypes in Atomic, one of the first interactive components you’re likely to make is navigation.
We often get asked about the ‘best’ patterns for navigation components, so that’s what we’re sharing in this article. There’s definitely no ‘right’ way to make navigation components, but some approaches are easier, more flexible and more reusable than others.
The most important thing to remember is that when you want a child component to control your top-level prototype, you need a way for the prototype to respond to what’s going on in the component.
Just want to grab a nav sample to use in your own project?
Let’s look at the main ways a component can influence the main prototype:
Pattern 1: Actions are added to the main prototype which watch the component and respond to its state changes.
Our view: an easy way to get started with components
This pattern is easy to use. After placing your component on a page, on that same page add action(s) that watch the component (either as page actions, or actions attached to the component instance). Each actions can watch for one state change scenario, for example, when Nav Component has changed to Home. Then you can specify what should happen in the main prototype, for example Go to Home (to change the main prototype to the “Home” page.
This pattern is a great when you’re just getting started with actions and components, but pretty soon you’ll discover it can be a lot of work to create actions for each state change scenario, especially when you need to set up all the actions again on each page the component is placed on.
So, this pattern is easy to learn and fast to get going with, but doesn’t scale very well. The next approach is to introduce variables.
Pattern 2: Components set variable values which the main prototype watches.
Our view: quick and flexible, but also doesn’t scale well
Variables are a simple way to pass values around your prototype. For example, when a user clicks Home in your navigation component, you could have that component set a value like “Home” into a variable named section. Then you could have an action in the main prototype configured to watch section which changes the main prototype to the page named “Home” when section is set to “Home”.
You might choose to set up one action per nav option, with each action configured to watch for a specific page name, but if you add too many, your prototype may start to get sluggish. Variable change events are constantly monitoring your document for changes, so having many of them causes your prototype to do a lot of work.
A better approach when using variable changes events for navigation, is to use a single variable changes action, which passes whatever value is set in the variable to a one-line script that changes the main prototype to whatever page matches the variable’s value.
Tip: even though you add variable change actions to a specific page, they continue to run and trigger regardless of which page is being displayed, so you don’t need to add more than one if the configuration would be the same.
This is a good pattern for smaller prototypes. But using variables and variable change events can usually be avoided completely, which is definitely our recommendation for most cases.
Pattern 3: Components use scripting to directly change the main prototype’s state.
Our view: flexible, scalable, reusable.
By far the cleanest pattern is for the component to run a simple script which directly changes the state of the parent prototype. Nearly all of the navigation examples we’ve prepared use this pattern, so you can copy them see the pattern in action.
Atomic offers two helpful script functions that enable one part of your prototype to directly change the state of another part. To change the page of the main prototype, you use the
goto() function, to change a component’s state, you use the
Because this approach uses scripting you can also extend it as far as you need. For example, you could wrap the
goto() function in a conditional if statement, or change the state of many components at the same time. If you’re a confident coder, you might even write an extended custom function to handle your page/state changes.
This is great entry-level scripting in Atomic. You definitely won’t need to be an experienced engineer to get it working!
So which pattern is best?
There’s no right way, but for super simple prototypes, component change actions are easy. For most everyday use cases, we strongly recommend you use scripting manage state changes.
To help you save time, use our samples as a starting point:
Tip: Navigation components can save other people in your team time, consider putting a copy in your team library.
Have ideas or questions about making navigation components in Atomic? Join the conversation in our community. New to Atomic? Know that it’s free to prototype in Atomic, easy to get started and insanely powerful!