This is a read-only archive of the Framer Community on Facebook.

What is Framer? Join the Community
Return to index
Josselin Ex-Nils
Posted Aug 13 - Read on Facebook

I've been experimenting lately with Framer, and I'd like to have your thoughts on a couple issues I have been dealing with (I'll do it in 2 posts for the sake of clarity)

I have recreated part of the Instapaper app which involve swipe gesture on list items to bring up options regarding the said item. But the swipe depending on its direction and the state of the ui can as well bring up the left menu or do nothing. From a UX perspective it makes sense. But to reproduce that in Framer I've had the following issues :

a. A list item on which a TouchStart event is triggered, does not receive the TouchEnd event if this is triggered on a sibling so I have to catch it higher up in the layer tree and store the information of the element on which the touch was started in order to take the proper action in the TouchEnd.

b. The next state following an event depends on several variables (TouchStart position, TouchEnd position, previous state,...) which to already some complexity in conditional statements for only a couple features

c. My code is already a mix of UI elements definition, states definition, event handler definitions, helper functions, state transition functions, with some global variables here and there... with no real structure

So my question is : are there any best practices regarding :

1. dealing with events and state transitions (I ended up having one big function handling all the events and going through the conditionals every time it is called) ?

2. modularizing code ?

(End of 1st part)


Koen Bok

1. No. I've seen different people doing different things successfull. I'd like to solve this specific case higher level in Framer, but the event propagation model in the browser does not make this easy.

2. You can use modules pretty easy for chunks of code you don't touch often / re-use across projects.

Read the entire post on Facebook