[How?] Handle overlays/modals in Vue way

[nolimits4web]

So the question is, how do you think to make it better to handle open/close/create modal/overlay components (like popups, date pickers, pickers, modals, popover, )etc. in a Vue-way? What is the best practise with it

[akralj]

there is an example on the vue.js website: https://vuejs.org/examples/modal.html maybe this is useful for you.

[bencompton]

I can't claim to grok Vue at this point, but with the React work I've done so far with F7, I've tried to make the components as stateless as possible so it will work with Redux, support time travel debugging, etc., which has turned out to be a hard (but IMO necessary) road because it makes it difficult to leverage the existing F7 JavaScript.

Is vuex support a priority at this point, or no? If so, I would imagine that opening and closing modals would be accomplished via an isOpen prop or something, along with CSS animation for the transitions between states. That of course pushes it to consumer's state management logic to side keep track of whether or not it should be open, which perhaps is not as simple as f7.alert, f7.confirm, etc., like you're currently doing here, but is necessary for supporting state management libraries like vuex, redux, etc.

Not sure about Vue, but another challenge with React is the fact that F7 modals need to be rendered directly in the body, whereas all of the React components are all rendered under their parents in the DOM. I ended up using React Portal to be able to render modals under any React component, but have still it put the modal in the correct place in the DOM directly under the body.

You can see an example in the side panel and its usage in the kitchen sink and see it in action here when you open the left panel. The kitchen sink doesn't use Redux or anything and instead keeps state in the consuming parent component for simplicity, but could just as well be using Redux or Mobx, or whatever.

Anyhow, I would imagine that all of this would be similar in the Vue implementation, but sorry if I'm misunderstanding your intent or showing my ignorance of Vue and none of this is really relevant.

[cornelisse]

I do not claim to understand Vue completely but I agree with Bencompton that the use of Vuex is for more complex cases my preferred solution.

[nolimits4web]

@bencompton

Not sure about Vue, but another challenge with React is the fact that F7 modals need to be rendered directly in the body, whereas all of the React components are all rendered under their parents in the DOM. I ended up using React Portal to be able to render modals under any React component, but have still it put the modal in the correct place in the DOM directly under the body.

Same with Vue, that is why i already introduced new F7 app parameter called root https://github.com/nolimits4web/Framework7/blob/master/src/js/f7-intro.js#L15 that will be in upcoming in few days 1.5.0 release of F7. In this case it (F7) adds and manages all overlays and app keeps app structure in same wrapping element as Vue/React root element

[bencompton]

So @nolimits4web, are you saying that modals will pretty much work the same way they do in F7 today, except that F7 Vue will provide a wrapper around the F7 API? It appears that is how routing and navigation also works: F7 Vue essentially provides a wrapper to integrate with existing F7 logic for routing, page DOM manipulation, and animation logic, etc.

Maybe I'm misunderstanding, and please correct me if I am, but in both of these cases, Framework7 would be keeping track of the relevant state, and also handling the logic for mutating that state, and of course this logic is also mixed in with rendering logic. This is at odds with libraries like Redux and VueX, where all state is expected to be in a central store and only mutated by actions, mutators, reducers, etc. With this approach, it seems that people who want to use VueX or Redux will have problems.

Firstly, do you consider supporting VueX (and other state management libraries like Redux, etc.) to be a priority for Framework7 Vue? If not, then I'll stop bugging you about it. :)

For framework7-react, I had imagined having the React components to be completely stateless, but then having an add-on library for Redux similar to react-router-redux that provided the relevant actions and reducers for common Framework7 concerns like modals and navigation. For example, this would show an alert:

import {showAlert} from 'framework7-react-redux';
import {store} from './my-store';

store.dispatch(showAlert('Some title', 'Some text'));

I can imagine that the same type of thing could be done for VueX. In VueX, I think it would be implemented as a store module (not positive).

[nolimits4web]

So @nolimits4web, are you saying that modals will pretty much work the same way they do in F7 today, except that F7 Vue will provide a wrapper around the F7 API?

No, at least not everything. I'm going to keep router and some animations/transitions routine for F7 as i don't see much sense to rewrite thousands lines of code which is already in F7 core and works good with Vue without affecting state. I already added option to control modals like Popup, Login Screen and Picker Modal by app state, and F7 used here only for transitions https://github.com/nolimits4web/Framework7-Vue/commit/5c75f67b6176d11b4e4797301ad56059d637cba4

Firstly, do you consider supporting VueX

Yes, but a little bit later. Now i have to bring all F7 basics work

[bencompton]

Thanks for the explanation. I think I'm coming around to your way of thinking now. I've been trying to build a "pure" React framework so far, and I initially imagined that you would be doing the same with Vue. However, I have come across so many cases where I have had to battle React + React Router that it doesn't seem worthwhile anymore. If anyone is interested in the specifics, see this issue.

Long story short, I'm now inclined to build an integration with the routing in F7 core as you suggested a while back and not supporting React Router. I'm also inclined to let F7 core handle modal animation and rendering as well. Framework7 React should come along a much faster this way, and I think this approach will actually work just fine with state management libraries like VueX or Redux, so long as:

1. The current route URL gets synced to the central store like react-router-redux does
2. Route changes can be controlled via actions

Perhaps both of these could be eased via add-on libraries for VueX / Redux like I suggested in my last post.

The only real downside I can think of is server rendering, since F7 will end up doing at least some of the rendering, which won't work on the server. I'm not sure whether anyone actually cares about server rendering with Framework7 or not anyhow.

[nolimits4web]

@bencompton totally agree with you in this approach! I also found it easiest and quickest way of integration, and also such approach will be easier to maintain and keep in track with native F7 lib

[nolimits4web]

I think we can close it