kirlat
commented
3 years ago The only thing that I don't like - that before we had a huge UIController with a lot of types of data handling. Now we have a huge Lexis module with various methods of getting data. And it tightly connected with the other code by Vuex.Strore.
From my point of view - it would be better to move to the structure, where Lexis - is an independent module, with independent input/output. May be it is an independent package - that could be used with various applications (as we discussed on the meeting). And this way it could be divided to smaller classes that would be more independent, supportable and extendable.
Moving methods for resource retrieval to Lexis is a temporary solution. This is intended to leave the code in some workable state so I can switch to the Annotation UI and return to the resource retrieval after that. My intention is to move retrieval of lemma translations, word usage examples, and full definitions behind the GraphQL facade, similar to the short definitions. @balmas, @irina060981: would you think it would be a good idea?
From my point of view, all the logic to get all kinds of morphological data should be behind the GraphQL facade, and that might be separated into a module of its own. Whatever needs the morphological data should use the GraphQL to retrieve it. So the purpose of the Lexis module is to know how to retrieve the morphological data from GraphQL and construct in-memory objects (Homonyms and others) out of the GraphQL data. But there are also parts that cannot go behind the GraphQL facade, such as the Treebank data retrieval. It requires a document to be loaded within an iframe on each request and it can be done only from the application side. This functionality is in Lexis too.
I think that probably we will rip the greatest benefits now from (if not to count standardization of morphological data retrieval trough GraphQL) straightening the code that synchronizes events of data retrieval and UI updates (that's what the app controller does mostly). Probably it would make sense to put greater effort in there, to standardize interactions, to make code more testable, to eliminate functions that does nothing more than calling some other function (i.e. to shorten the call stack chains). But I think the ultimate priority should be the changes that adds value (i.e. that satisfy business requirements).
What do you think?
balmas
This is a fix for the #562. It also tries to make architecture more flexible in order to satisfy #566 requirements. Resource retrieval for lemma translations, word usage examples, and short definitions have been separated into its own functions and moved into the Lexis. They do not have dependency on the LexicalQuery any more.
There were also some minor code improvements. Dependencies were updated to the latest versions, whenever it was possible without breaking the existing functionality.