Tightly coupled components refactory

[EnricoBarbieri1997]

Components (in particular the ones inside BottomSheet) needs to be refactored because some are tightly coupled with stores, outer most components and BottomSheet. For the ones tightly coupled with stores or controllers is enough to have a version where everything is a prop and a version that calculates the current logic and passes it down as prop. Not every component that access stores or models directly needs to be changed but there are a lot of general components that can't be reused because instead of having generic event handlers they have a very specific model passed to it

[EnricoBarbieri1997]

I will provide an initial list with examples of which ones are fine and which ones are not as soon as possible

[EnricoBarbieri1997]

Examples of it are:

• PinCode: it takes as props a Pin class instead of a general value, onChange pair. We could have a base component that just takes the value and the event and another one that builds on top of it that uses this Pin class. If you do want to have 2 events for press and remove it's fine. The problem here is not the events subdivision but the dependency on Pin class.
• Footer files: there are at least a couple of footer files (with slightly different style) that are inside the screens they are used into. Why don't we move them out? They have similar functionalities and could be used elsewhere in the future.
• SendRecap/Recap: takes as input a controller/creater. I'm not sure about this paradigm. It's the first time that I've encountered it. Mixing multiple inputs prevents passing a lot of props around but makes inner components cryptic as they don't explicitly list their props.