Added support for the lexical query failure #565

kirlat · 2020-12-02T18:03:11Z

This build fixes the #562 and adds some related improvements to the GraphQL API.

Here is the short summary of changes:

The word GraphQL query response has been updated according to the results of the discussion in morph adapter errors shouldn't fail the query if there are also valid results #562. If the query failed completely, then the homonyms field in the response will be null and there will be errors in the error field. If the query failed only partially, then the homonyms field will contain homonyms data and the errors field will contain warnings.
Warnings were added to both client adapters and the GraphQL backend.
I've started to add error codes to more error and warning objects. I think error codes are important if we want to identify what type of error it is (i.e. if (errCode ===A) {}) and act accordingly. The good thing about error codes is that they can be transferred from object to object and even across the network.

Please let me know what do you think.

…562)

…tch GraphQL specs

kirlat · 2020-12-02T18:04:48Z

packages/client-adapters/src/errors/adapter-error.js

-
- update (config) {
- this.adapter = `${config.category}.${config.adapterName}`
- this.methodName = config.method
-
- this.message = `${this.message} (${this.adapter}.${this.methodName})`
- return this
- }


I did not find it to be used anywhere so I've decided to remove the unused code. Please let me know if this code is needed and I will return it back.

it might be safer to leave it in, marked as deprecated.

I don't remember the history of this part of code unfortunately.

That's a good idea, I will do that (i.e. mark it as deprecated)

kirlat · 2020-12-02T18:05:32Z

packages/client-adapters/src/errors/remote-error.js

-
- update (config) {
- this.adapter = `${config.category}.${config.adapterName}`
- this.methodName = config.method
-
- this.message = `${this.errorCode}: ${this.message} (${this.adapter}.${this.methodName})`
- return this
- }


Same is above, I think it is not used any more.

same as above (leave in mark as deprecated)

Will mark it as deprecated.

kirlat · 2020-12-02T18:07:06Z

packages/client-adapters/src/errors/warning-codes.js

+const WarningCodes = {
+ /*
+ `hdwd` field of the response of the morphological adapter contains a number, not a string
+ */
+ NO_LEMMA_IN_HDWD: 'NO_LEMMA_IN_HDWD'
+}


I think it is good to have a centralized list of error codes. This way the client will know what kinds of errors to expect from the library (this file can be imported by the client app if necessary).

I agree, but wonder about the best way to be consistent about how these are translated to text in the UI. Maybe we also need a locales file specific to errors and warnings?

(e.g. note that this particular warning is coupled with a retrieval of the message named MORPH_TRANSFORM_NO_LEMMA in the adapter code that uses this warning)

I have a question, we have two similiar classes now
AdapterError and AdapterWarning

We use errorCode from the response for RemoteError and errorCode for AdapterWarning.
ErrorCodes for RemoteErrors you defined inside alpheios-messaging
ErrorCodes for Warnings you defined inside client-adapters packages

So this way we need to know exactly the class source of the errorCode to be able to analyze it.
Because otherwises - it is only a String and not any short code.
May be it is better to think how to unify it the way you could retrieve all the data about the error from the error source? Similiar to Response errors from web server (404, 500 and so on)?

I was having similar thoughts myself. I think we should somehow harmonize errors between different parts of the application, and think about localization of error messages. That could be a topic requiring some thought and discussion. It's probably better to create an issue for that. What do you think?

I think it is worth to be placed to a separate issue.

kirlat · 2020-12-02T18:10:33Z

packages/components/src/app/word-query/word-query-controller.js

 if (loading === false) {
 watchableQuery.stopPolling()
 }
 if (counter >= maxIterations) {
 watchableQuery.stopPolling()
 }
 counter++
- dataCallback(data.word.homonyms, data.word.state, data.word.errors)
+ dataCallback(data.word)


I think it's better to pass the whole response the the calling function rather than parse it here: it might know better how to deal with the data returned.

kirlat · 2020-12-02T18:11:40Z

packages/components/src/data-model/constants/error-codes.js

 TUFTS_ERROR: 'TUFTS_ERROR',
 TREEBANK_ERROR: 'TREEBANK_ERROR',
 LEXICONS_ERROR: 'LEXICONS_ERROR',
 DISAMBIGUATION_ERROR: 'DISAMBIGUATION_ERROR',
 SHORT_DEFS_ERROR: 'SHORT_DEFS_ERROR'
 }
-export default WordQueryErrorCodes
+export default ErrorCodes


I think this list of error codes can belong not to WordQuery only but can be shared across other queries. Hence the renaming.

kirlat · 2020-12-02T18:12:16Z

packages/components/src/data-model/constants/error-origins.js

+ CLIENT_ADAPTERS: 'ClientAdapters',
+ DISAMBIGUATED_DATA_OBJECT: 'DisambiguatedDataObject'
+}
+export default ErrorOrigins


These are the modules where errors and warnings might be produced.

kirlat · 2020-12-02T18:13:43Z

packages/components/src/data-model/constants/error-severity-types.js

+const ErrorSeverityTypes = {
+ ERROR: 'Error',
+ WARNING: 'Warning'
+}
+export default ErrorSeverityTypes


This is a way to distinguish between an error and a warning within the GraphQL error object (as GraphQL specs do not support a warning type).

kirlat · 2020-12-02T18:15:29Z

packages/components/src/data-model/word-query/error/error-mapper.js

+ } else if (clientAdaptersErrorOrWarning.constructor.name === 'AdapterWarning') {
+ return new WordQueryWarning(...params)
+ } else {
+ throw new Error(`Unsupported error type: ${clientAdaptersErrorOrWarning.constructor.name}`)


I think we need this for development to catch unsupported error objects (do not have any now). The exception will force us to fix the problem.

kirlat · 2020-12-02T18:16:50Z

packages/components/src/data-model/word-query/error/word-query-warning.js

+ */
+ constructor (message, code, warnData = {}) {
+ super(message, code, warnData)
+ this.extensions.severity = ErrorSeverityTypes.WARNING


Same as error, but with a different severity.

kirlat · 2020-12-02T18:18:47Z

packages/components/src/data-model/word-query/word-query-response.js

+ data: {
+ homonyms: this.homonymGroup ? this.homonymGroup.homonyms.map(h => h.convertToJSONObject(true)) : []
+ },
+ extensions: {
+ state: JSON.parse(JSON.stringify(this.state))
+ }


The response format has been updated to match the latest GraphQL specs.

kirlat · 2020-12-02T18:20:32Z

packages/components/src/vue/vuex-modules/data/lexis.js

 variables,
 source
 })
 } catch (err) {
 Logger.getInstance().error('Observable word query error', err)
 }

- if (homonym) {
+ if (wqData && wqData.homonym) {


If there is something returned in the homonym field, request succeeded fully or partially.

balmas

This mostly looks good to me, I just had some small questions and change requests.

I'm also wondering if it's possible to add an integration test that tests this specific bug, i.e. creating a fixture in the alpheios-fixtures package, and testing that a query on 'caro' succeeds. I don't think we have integration tests for the new lexical query code yet, but having this sort of test for the inflection-tables has been enormously helpful (actually essential) to facilitating refactoring of that code. I think we need to start having similar tests here too. E.g. see the verified-issues.test.js in inflection-tables/tests/data

balmas · 2020-12-02T19:33:08Z

packages/client-adapters/src/errors/adapter-error.js

-
- update (config) {
- this.adapter = `${config.category}.${config.adapterName}`
- this.methodName = config.method
-
- this.message = `${this.message} (${this.adapter}.${this.methodName})`
- return this
- }


it might be safer to leave it in, marked as deprecated.

balmas · 2020-12-02T19:33:22Z

packages/client-adapters/src/errors/remote-error.js

-
- update (config) {
- this.adapter = `${config.category}.${config.adapterName}`
- this.methodName = config.method
-
- this.message = `${this.errorCode}: ${this.message} (${this.adapter}.${this.methodName})`
- return this
- }


same as above (leave in mark as deprecated)

balmas · 2020-12-02T19:36:48Z

packages/client-adapters/src/errors/warning-codes.js

+const WarningCodes = {
+ /*
+ `hdwd` field of the response of the morphological adapter contains a number, not a string
+ */
+ NO_LEMMA_IN_HDWD: 'NO_LEMMA_IN_HDWD'
+}


I agree, but wonder about the best way to be consistent about how these are translated to text in the UI. Maybe we also need a locales file specific to errors and warnings?

balmas · 2020-12-02T19:38:18Z

packages/client-adapters/src/errors/warning-codes.js

+const WarningCodes = {
+ /*
+ `hdwd` field of the response of the morphological adapter contains a number, not a string
+ */
+ NO_LEMMA_IN_HDWD: 'NO_LEMMA_IN_HDWD'
+}


(e.g. note that this particular warning is coupled with a retrieval of the message named MORPH_TRANSFORM_NO_LEMMA in the adapter code that uses this warning)

balmas · 2020-12-02T19:41:33Z

packages/components/src/app/word-query/word-query-controller.js

 if (loading === false) {
 watchableQuery.stopPolling()
 }
 if (counter >= maxIterations) {
 watchableQuery.stopPolling()
 }
 counter++
- dataCallback(data.word.homonyms, data.word.state, data.word.errors)
+ dataCallback(data.word)


balmas · 2020-12-02T19:44:42Z

packages/components/src/data-model/word-query/error/word-query-error.js

@@ -14,34 +21,48 @@ export default class WordQueryError {
 * Creates an instance of WordQueryError.
 *
 * @param {string} message - An error message.
- * @param {import('./word-query-error-codes.js').WordQueryErrorCodes} code - An error code.
- * It is required to match Apollo GraphQL convention for errors.
+ * @param {import('../../constants/error-codes.js').ErrorCodes} errCode - An error or a warning code.
 * @param {string[]} path - A path (a sequence of component names) where an error occurred.


path is no longer a supported parameter here, right?

balmas · 2020-12-02T19:47:54Z

packages/components/src/data-model/word-query/error/word-query-error.js

 }
 this.message = message
- this.path = path
+ this.path = ['word']


just noting that this is very different than the way the path was set before.

I've changed it to be more in line with the GraphQL specs. According to those, it should be a path within the GraphQL response to the elements that failed (see http://spec.graphql.org/draft/#example-90475 as an example). Since we do not have an exact element that failed (but may have that in the future) I decided to use the generic word element. No looking at the example more closely I realize that it would be better to use homonyms instead. I will do that change, if you don't mind.

Ideally we should identify the exact homonym and the lexeme that failed, but I'm not sure how easy will it be to do now.

I will do that change, if you don't mind.

ok thanks

balmas · 2020-12-02T19:59:46Z

packages/client-adapters/src/transformers/alpheios-lexicon-transformer.js

@@ -181,14 +182,13 @@ class AlpheiosLexiconTransformer {
 // and not a String
 const lemmaText = elem.hdwd && elem.hdwd.$ ? `${elem.hdwd.$}` : ''
 if (!lemmaText) {
- this.adapter.addError(this.adapter.l10n.getMsg('MORPH_TRANSFORM_NO_LEMMA'))
+ this.adapter.addWarning(WarningCodes.NO_LEMMA_IN_HDWD, this.adapter.l10n.getMsg('MORPH_TRANSFORM_NO_LEMMA'))


I think we also have to convert all of the other errors in this class to warnings rather than errors. (e.g. on lines 164 and 239)

irina060981 · 2020-12-03T01:13:04Z

@kirlat and @balmas, I have a question here about wordList workflow.
We could have such a case, when the morph adapter doesn't return the result, but we need to have an empty homonym (or may be some other format) to save this word to the wordList with the current context.

For example (from embed-lib index.html),

No, I am not sure, but I believe we didn't get any homonym and it is not saved to the wordlist now.
Do we decide not to track such words in wordlist with only the context?

irina060981 · 2020-12-03T01:21:20Z

The second case with Persian words.
There was done a workflow with a warning before.
When we didn't get lexical results , we show a notification for the user that he/she should wait for definitions.

For now we lost this behaviour, I couldn't found my PR with this change ad couldn't even find the notice with such a text.
Do we remove this feature?

irina060981 · 2020-12-03T01:26:43Z

Also I have a question
now we have two progress bars at the same time in popup

I believe the second one is for short definitions, but what does mean the first progress? According to my case in the screenshot all morph data is retrieved from the source

irina060981

I don't have any code notes , but have some questions about the final result.

irina060981 · 2020-12-03T00:28:11Z

packages/client-adapters/src/errors/adapter-error.js

-
- update (config) {
- this.adapter = `${config.category}.${config.adapterName}`
- this.methodName = config.method
-
- this.message = `${this.message} (${this.adapter}.${this.methodName})`
- return this
- }


I don't remember the history of this part of code unfortunately.

irina060981 · 2020-12-03T01:53:01Z

packages/client-adapters/src/errors/warning-codes.js

+const WarningCodes = {
+ /*
+ `hdwd` field of the response of the morphological adapter contains a number, not a string
+ */
+ NO_LEMMA_IN_HDWD: 'NO_LEMMA_IN_HDWD'
+}


I have a question, we have two similiar classes now
AdapterError and AdapterWarning

We use errorCode from the response for RemoteError and errorCode for AdapterWarning.
ErrorCodes for RemoteErrors you defined inside alpheios-messaging
ErrorCodes for Warnings you defined inside client-adapters packages

So this way we need to know exactly the class source of the errorCode to be able to analyze it.
Because otherwises - it is only a String and not any short code.
May be it is better to think how to unify it the way you could retrieve all the data about the error from the error source? Similiar to Response errors from web server (404, 500 and so on)?

kirlat · 2020-12-03T07:53:51Z

We could have such a case, when the morph adapter doesn't return the result, but we need to have an empty homonym (or may be some other format) to save this word to the wordList with the current context.

The second case with Persian words.
There was done a workflow with a warning before.
When we didn't get lexical results , we show a notification for the user that he/she should wait for definitions.

Thanks for catching this! I've missed those two cases during my testing. I will review them and see what's going on. I think we would need to create integration tests for them, if possible.

For now we lost this behaviour, I couldn't found my PR with this change ad couldn't even find the notice with such a text.
Do we remove this feature?

I don't remember removing it specifically. @irina060981, can you recall the number of your PR? I can try to track changes from it to see what happened with the code since then.

…ecated, per the review suggestions

kirlat · 2020-12-03T12:18:12Z

now we have two progress bars at the same time in popup

I believe the second one is for short definitions, but what does mean the first progress? According to my case in the screenshot all morph data is retrieved from the source

The upper progress bar is for the overall lexical query request. It disappears when the LEXICAL_QUERY_COMPLETE event is published at the finalize() method of the LexicalQuery, or in some other places if request fails.

The lower progress bar is for short definitions. It disappears when either short definitions are retrieved or when we figure out that there are no short definitions for this word.

@balmas, what would be the desired UI here? Both bars could make sense (especially if to change the wording a little bit), or we can show one or the other.

We can, for example, use the upper bar for the lexeme retrieval and it can say something like "Lexemes are loading" and then the lower bar for short definitions ("Short definitions are loading"). First the upper bar will disappear and then the lower bar will follow suit, when short definitions' retrieval will be complete. This might give users a more detailed insight about what's going on behind the scenes.

balmas · 2020-12-03T13:38:59Z

@kirlat and @balmas, I have a question here about wordList workflow.
We could have such a case, when the morph adapter doesn't return the result, but we need to have an empty homonym (or may be some other format) to save this word to the wordList with the current context.

For example (from embed-lib index.html),

No, I am not sure, but I believe we didn't get any homonym and it is not saved to the wordlist now.
Do we decide not to track such words in wordlist with only the context?

this is a good point. What should happen when you lookup a word without results is that the word should be added to the wordlist with itself as a lemma -- e.g. in these lines of the production lexical query, if we have no result form the morph adapter, we create a homonym with the form itself as the lemma:
https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/queries/lexical-query.js#L181-L182

balmas · 2020-12-03T13:40:48Z

now we have two progress bars at the same time in popup

I believe the second one is for short definitions, but what does mean the first progress? According to my case in the screenshot all morph data is retrieved from the source

The upper progress bar is for the overall lexical query request. It disappears when the LEXICAL_QUERY_COMPLETE event is published at the finalize() method of the LexicalQuery, or in some other places if request fails.

The lower progress bar is for short definitions. It disappears when either short definitions are retrieved or when we figure out that there are no short definitions for this word.

@balmas, what would be the desired UI here? Both bars could make sense (especially if to change the wording a little bit), or we can show one or the other.

We can, for example, use the upper bar for the lexeme retrieval and it can say something like "Lexemes are loading" and then the lower bar for short definitions ("Short definitions are loading"). First the upper bar will disappear and then the lower bar will follow suit, when short definitions' retrieval will be complete. This might give users a more detailed insight about what's going on behind the scenes.

I would defer to @monzug on what should happen in the UI here.

monzug · 2020-12-03T14:20:48Z

"lexical data is loading" message is generated while loading the morphology pop-up. when morphology pop-up is generated the message does not show up anymore. In the case of λεπτοψαμάθων it does briefly co-exist with the loading of the short definition progress bar in some cases (e.g. first look up of a Greek word) then it does quickly fade away. I am ok with it.

balmas · 2020-12-03T16:11:03Z

"lexical data is loading" message is generated while loading the morphology pop-up. when morphology pop-up is generated the message does not show up anymore. In the case of λεπτοψαμάθων it does briefly co-exist with the loading of the short definition progress bar in some cases (e.g. first look up of a Greek word) then it does quickly fade away. I am ok with it.

Thanks @monzug . So @kirlat let's leave this for now.

kirlat · 2020-12-03T16:34:07Z

this is a good point. What should happen when you lookup a word without results is that the word should be added to the wordlist with itself as a lemma -- e.g. in these lines of the production lexical query, if we have no result form the morph adapter, we create a homonym with the form itself as the lemma:
https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/queries/lexical-query.js#L181-L182

I've examined the code carefully and it seems that the WordList controller does not listen to the MORPH_DATA_READY event at all. It subscribes to HOMONYM_READY instead: https://github.com/alpheios-project/alpheios-core/blob/production/packages/wordlist/src/controllers/wordlist-controller.js#L13-L21

In the LexicalQuery a Homonym is constructed even if the morph data request fails (at the point that Bridget referenced in the quote above), and then, a few lines below, this Homonym object used in the HOMONYM_READY event: https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/queries/lexical-query.js#L217-L247.

So it seems that in the current workflow, even if the morphological query failes, we still create a homonym from a target word nonethless nonetheless and, depending on the configuration, try to retrieve short definitions, full definitions, lemma translations, and word usage examples. Should we keep it this way? If so, for failed request the new workflow should create a Homonym, and pass it to the Lexical Query. Not sure how to be with short definitions in this case since those are retrieved behind the GraphQL facade. Should the GraphQL backend create a Homonym even if no morph data is available and try to retrieve short definitions for it?

Analyzing the code, I've discovered that MORPH_DATA_READY event is kind of a duplicate of HOMONYM_READY in our current workflow. There is only one subscriber for this event: https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/controllers/app-controller.js#L1150-L1152. All it does is updates the text message. I think we can move the message update to the onHomonymReady() method and get rid of MORPH_DATA_READY completely.

@balmas, @irina060981 please let me know what do you think about the desired workflow.

kirlat · 2020-12-03T16:36:14Z

"lexical data is loading" message is generated while loading the morphology pop-up. when morphology pop-up is generated the message does not show up anymore. In the case of λεπτοψαμάθων it does briefly co-exist with the loading of the short definition progress bar in some cases (e.g. first look up of a Greek word) then it does quickly fade away. I am ok with it.

Thanks @monzug . So @kirlat let's leave this for now.

Maybe we should change the text for the lower progress bar to Short definitions are loading? It might be more understandable what this bar is for this way. What do you think?

balmas · 2020-12-03T16:46:25Z

"lexical data is loading" message is generated while loading the morphology pop-up. when morphology pop-up is generated the message does not show up anymore. In the case of λεπτοψαμάθων it does briefly co-exist with the loading of the short definition progress bar in some cases (e.g. first look up of a Greek word) then it does quickly fade away. I am ok with it.

Thanks @monzug . So @kirlat let's leave this for now.

Maybe we should change the text for the lower progress bar to Short definitions are loading? It might be more understandable what this bar is for this way. What do you think?

Yes ! I think that's a very good idea. Thank you!

monzug · 2020-12-03T17:07:19Z

Absolutely, YES

…

On Thu, Dec 3, 2020 at 11:46 AM Bridget Almas ***@***.***> wrote: "lexical data is loading" message is generated while loading the morphology pop-up. when morphology pop-up is generated the message does not show up anymore. In the case of λεπτοψαμάθων it does briefly co-exist with the loading of the short definition progress bar in some cases (e.g. first look up of a Greek word) then it does quickly fade away. I am ok with it. Thanks @monzug <https://github.com/monzug> . So @kirlat <https://github.com/kirlat> let's leave this for now. Maybe we should change the text for the lower progress bar to Short definitions are loading? It might be more understandable what this bar is for this way. What do you think? Yes ! I think that's a very good idea. Thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ32UOP6J4GZMODJFXY323LSS66HFANCNFSM4UK264MA> .

kirlat · 2020-12-03T17:17:32Z

Yes ! I think that's a very good idea. Thank you!
Absolutely, YES

Will update the text accordingly.

balmas · 2020-12-03T17:46:33Z

I've examined the code carefully and it seems that the WordList controller does not listen to the MORPH_DATA_READY event at all. It subscribes to HOMONYM_READY instead: https://github.com/alpheios-project/alpheios-core/blob/production/packages/wordlist/src/controllers/wordlist-controller.js#L13-L21

In the LexicalQuery a Homonym is constructed even if the morph data request fails (at the point that Bridget referenced in the quote above), and then, a few lines below, this Homonym object used in the HOMONYM_READY event: https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/queries/lexical-query.js#L217-L247.

So it seems that in the current workflow, even if the morphological query failes, we still create a homonym from a target word nonethless nonetheless and, depending on the configuration, try to retrieve short definitions, full definitions, lemma translations, and word usage examples. Should we keep it this way? If so, for failed request the new workflow should create a Homonym, and pass it to the Lexical Query. Not sure how to be with short definitions in this case since those are retrieved behind the GraphQL facade. Should the GraphQL backend create a Homonym even if no morph data is available and try to retrieve short definitions for it?

Analyzing the code, I've discovered that MORPH_DATA_READY event is kind of a duplicate of HOMONYM_READY in our current workflow. There is only one subscriber for this event: https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/controllers/app-controller.js#L1150-L1152. All it does is updates the text message. I think we can move the message update to the onHomonymReady() method and get rid of MORPH_DATA_READY completely.

@balmas, @irina060981 please let me know what do you think about the desired workflow.

Per discussion in Slack, the current production code is a bit of a hack, that allows us to continue to lookup a word in the additional resources (short definitions, full definitions, usage examples, etc) even if we fail to parse a lemma in the morphology service.

I think we still want to do that, but I want to expand the data model so that we don't pretend the form is a "lemma" . This is described further in alpheios-project/documentation#33

Aside from making the code easier to understand and less error-prone, and supporting the additional use cases for the queries, our annotation workflows will require us to be explicit about what is being annotated, and we don't want to misrepresent an unparsed word form as a lemma as an annotation target.

kirlat · 2020-12-03T18:04:57Z

Analyzing the code, I've discovered that MORPH_DATA_READY event is kind of a duplicate of HOMONYM_READY in our current workflow. There is only one subscriber for this event: https://github.com/alpheios-project/alpheios-core/blob/production/packages/components/src/lib/controllers/app-controller.js#L1150-L1152. All it does is updates the text message. I think we can move the message update to the onHomonymReady() method and get rid of MORPH_DATA_READY completely.

@balmas, @irina060981: do you think we can remove the MORPH_DATA_READY event?

irina060981 · 2020-12-04T04:09:06Z

For now we lost this behaviour, I couldn't found my PR with this change ad couldn't even find the notice with such a text.
Do we remove this feature?
I don't remember removing it specifically. @irina060981, can you recall the number of your PR? I can try to track changes from it to see what happened with the code since then.

I couldn't find the PR it was rather long ago.
But I found that it was produced inside

  onMorphDataNotFound () {
    this._store.commit('ui/setNotification', { text: this.api.l10n.getMsg('TEXT_NOTICE_MORPHDATA_NOTFOUND'), important: true })
    this._store.commit('app/setQueryStillActive', true)
  }

@balmas, @irina060981: do you think we can remove the MORPH_DATA_READY event?

We have a workflow for MORPH_DATA_NOTAVAILABLE.
If we don't need this message:

  onMorphDataReady () {
    this._store.commit('ui/addMessage', this.api.l10n.getMsg('TEXT_NOTICE_MORPHDATA_READY'))
  }

I believe we could remove it.

kirlat · 2020-12-04T07:02:38Z

In our current workflow the HOMONYM_READY is published right after the MORPH_DATA_READY event. So if we'll move
this._store.commit('ui/addMessage', this.api.l10n.getMsg('TEXT_NOTICE_MORPHDATA_READY')) to the beginning of the onHomonymReady() handler the result should be almost the same, and we'll be able to simplify our workflow a little bit with that.

kirlat · 2020-12-04T07:05:06Z

As discussed with @balmas, I will merge the current PR with the current changes and two small additional fixes, and will implement other changes discussed as separate PR(s). This is to prevent discussion in the current PR from becoming too big.

…rned from GraphQL queries

# Conflicts: # packages/client-adapters/dist/alpheios-client-adapters.js.map # packages/client-adapters/dist/alpheios-client-adapters.min.js # packages/client-adapters/dist/alpheios-client-adapters.node.js.map # packages/client-adapters/dist/alpheios-client-adapters.node.min.js # packages/components/dist/alpheios-components.js # packages/components/dist/alpheios-components.js.map # packages/components/dist/alpheios-components.min.js

Kirlat added 6 commits November 24, 2020 13:41

WIP

77f935d

getWordData query would not fail if some data is available partially (#…

e3d6fff

…562)

Updated a GraphQL response format in accordance to specifications

e7847aa

Fixed a broken test

d1c3bb0

Removed a duplicated test suite

e194645

Added warnings to the client adapters. Updated GraphQL response to ma…

6a81c9c

…tch GraphQL specs

kirlat requested review from balmas and irina060981 December 2, 2020 18:03

kirlat commented Dec 2, 2020

View reviewed changes

balmas requested changes Dec 2, 2020

View reviewed changes

irina060981 requested changes Dec 3, 2020

View reviewed changes

Returned methods that were removed previously and marked them as depr…

2864bf7

…ecated, per the review suggestions

kirlat mentioned this pull request Dec 3, 2020

Refactor the resource retrieval workflow #566

Open

Kirlat added 3 commits December 4, 2020 11:26

Updated progress bar text for short definitions and a path field retu…

4e27352

…rned from GraphQL queries

Rebuilt after merge, fixed issues in tests

39f556a

kirlat merged commit 39f556a into master Dec 4, 2020

kirlat mentioned this pull request Dec 4, 2020

Standardize error format across modules #567

Open

kirlat deleted the i562-partial-lexquery-failure branch December 4, 2020 08:11

Added support for the lexical query failure #565

Added support for the lexical query failure #565

Conversation

kirlat commented Dec 2, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kirlat Dec 3, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

balmas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

irina060981 commented Dec 3, 2020

irina060981 commented Dec 3, 2020

irina060981 commented Dec 3, 2020

irina060981 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kirlat commented Dec 3, 2020

kirlat commented Dec 3, 2020 • edited Loading

balmas commented Dec 3, 2020

balmas commented Dec 3, 2020

monzug commented Dec 3, 2020

balmas commented Dec 3, 2020

kirlat commented Dec 3, 2020

kirlat commented Dec 3, 2020

balmas commented Dec 3, 2020

monzug commented Dec 3, 2020 via email

kirlat commented Dec 3, 2020

balmas commented Dec 3, 2020 • edited Loading

kirlat commented Dec 3, 2020

irina060981 commented Dec 4, 2020

kirlat commented Dec 4, 2020

kirlat commented Dec 4, 2020

kirlat Dec 3, 2020 •

edited

Loading

kirlat commented Dec 3, 2020 •

edited

Loading

balmas commented Dec 3, 2020 •

edited

Loading