add clickaway directive to games-panel

[irina060981]

Add an ability to close game panel with clickaway directive (the same as for components)

[irina060981]

@kirlat , I don't quitely understand your suggestion - do you suggest to modify the clickaway directive as quitely independent module with some parameters (we need to identify ignore html blocks like alpheios-popup, alpheios-panel and for my case alpheios-games). And then exclude it from components and inflection-games and use at as a separate repo published to npm? It sounds as independent project :)

[kirlat]

@irina060981, I just noticed that vue-clickaway is already available as an npm package: https://www.npmjs.com/package/vue-clickaway. So maybe we can just include vue-clickaway to a list of our dev dependencies, import, and use it. What do you think?

[irina060981]

@kirlat, It is not the same - I took it as a base for my code of the directive - and changed it to our purposes, and after that it was changed by me and Bridget (if I remember right). It has links to our specific parameters (as I described above). So If I will just include vue-clickaway to a list of our dev dependencies it won't work as expected. So I am not agree with your suggestion - may be I couldn't understand it correctly - and you could change the code (make some commits) and show what do you mean exactly? May be it could be easier to do it in components repo (it has the same tool there).

[kirlat]

Oh, I did not realize that our file was modified. Then, of course, using vue-clickaway npm package is not an option. But I like your idea (if I understand it correctly) to have one version of a directive file in our components repo and use it everywhere we need this functionality. This will follow DRY principle. What do you think? Is it possible to do? @balmas, what's your opinion on this?

[irina060981]

No, I didn't do this way - because there is another way to attach modules.

alpheios-inflection-games are imported to alpheios-components so it is independent from its structure and refactoring.

If I will import clickway directive there will be a link alpheios-components <-> alpheios-inflection-games

it seems to me that it is not a correct linking between modules.

I think it is a better way to create some external library for all repos that used some common vue-tools and technique (components, games, lexical-tests and so on) and avoid to import a big and interactive alpheios-components.

[kirlat]

Oh, I see. Agree that circular dependencies are bad. We can think about some better organization in the future.

I thought that components could be that kind of UI library of visual components that are shared among end products (safari app extension, webextension, PWA). So I'm thinking maybe we could include inflection games into components under its own directory as it seems to be a set of UI components that might be used by the end products too (not now but some time in the future)? They seem to have similar purpose other UI components and probably should be together. It will also greatly simplify dependency handling. What do you think?

[irina060981]

I have created it separately and made efforts to make it as much independent as it could (you could see that it has very less specific code in ui-controller.js of alpheios-components), because it was defined this way in the Bridget's task. If I understood it right it should be easily attached to something else in future :)

[kirlat]

If we need to have games independent, then they should probably be not included by components. They should be included at the final assembly point: in an end application that will use them (PWA, webextension, etc.).

I've checked components code and I've noticed that GamesController is used within a UI contorller. Probably in the future we should make it more flexible so that GamesController be somehow injected into a UI controller at the final assembly point or maybe subscribe to UI controller notifications (as about language change) and UI controller would stay truly universal. This will allow to untangle those dependencies. Something to think about during refactoring, probably.

[irina060981]

Yes, it is only the first version - and the conditions of the task were to have a homonym as input and to have a game as output (independent from inflections tab, for example).

So I attached it the most simple way to avoid spending time on creating some greater independence without having more concrete requirements where it would be used exactly (to avoid creating it more complex as it needs for defining game workflows and design).

So the next step should be woking on game's workflow after getting user's feedback. And then if I understood Bridget right it would be defined where and what way should it be placed and what should be the mechanism of attaching it to the extensions.

So If I am right the plan is near this (I believe, @balmas will correct me if I am wrong):

1) Work on game/games workflows after getting user's feedback

2) Apply some designs from UI design (it is not the strongest part of the inflection's games now :) ) and also how should it look on mobile layout (it was also a part of the requirement to be able to use some responsive or specific for mobile design)

3) Define where should it be used and how should it be added to projects

[balmas]

This is all a good conversation :-)

Yes I think it is too soon to optimize exactly how and where the inflection-games live and their exact interaction with the other code. I liked @irina060981 's approach because it is very easy to add or remove the feature, e.g. in the embedded library without having any impact on any of the other functionality. This makes it easy to test as a prototype but it's quite possible that in the future we need it to be more interactive with other pieces of the interface too.

I agree with @kirlat that embedding the GamesController within UIController is not ideal for the long run, but don't want to worry too much about the best way right now. This should all feed into refactoring thoughts though.