Revamp search results header #462
Conversation
I want the more 'important' specs to be higher up in the file
|
Test summary
Run details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
|
Test summary
Run details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
This reverts commit 3fdc6a3.
Codecov Report
@@ Coverage Diff @@
## master #462 +/- ##
==========================================
+ Coverage 86.38% 86.45% +0.06%
==========================================
Files 67 67
Lines 2637 2650 +13
==========================================
+ Hits 2278 2291 +13
Misses 359 359
Continue to review full report at Codecov.
|
|
@aarppe, note: once this is merged, I'd shorten the inflectional category information for N+*+D forms. They're a bit... noisy:
|
CreeDictionary/API/models.py
Outdated
| Attempts to get a description, e.g., "like: wîcihêw" or "like: | ||
| micisow" for this wordform. | ||
| Attempts to get an emoji description of the full wordclass. | ||
| e.g., "👤👵🏽" for "nôhkom" | ||
| """ | ||
| maybe_full_word_class = self.full_word_class |
There was a problem hiding this comment.
I have some thoughts regarding this full_word_class property.
Our Wordform model has a non-standard pos field (as part of speech is depreacted), which should be replaced to a word_class field.
But if we are switching to a JIT paradigm, the way of calculating full_word_class on the fly is a good way to start.
BTW, shouldn't it be just "word_class"? The "full" is unnecessary to me.
There was a problem hiding this comment.
Sure! I'll rename it to word_class!
|
|
||
|
|
||
| # XXX: mypy can't infer this type? | ||
| PER_REQUEST_ID_COUNTER = WeakKeyDictionary() # type: WeakKeyDictionary |
There was a problem hiding this comment.
does WeakKeyDictionary help with memory leak because the keys are garbaged collected as soon as the reference counter to the dictionary is 0?? Want some explanation.
There was a problem hiding this comment.
Correct! When the Response object reaches a reference count of 0, the key in the dictionary is invalid, and thus, its data can be deleted
|
|
||
|
|
||
| @register.filter | ||
| def unique_id(context: Any) -> str: |
There was a problem hiding this comment.
https://docs.djangoproject.com/en/3.0/howto/custom-template-tags/
So I think "filters"( {{ ]}) takes arbitrary value, and "tags" ({% %}) are the ones that are meant to take in context? You may want to use django's @register.simple_tag(takes_context=True) here
There was a problem hiding this comment.
I debated A LOT about this. You're right; context makes more sense, but the fact that I needed to assign and recall the ID twice makes creating a template tag... annoying... I'll give it some more thought :/
This tackles the following:
EDIT: it's ready! Here are some screenshots:
non-lemma form with definition:
its linguistic breakdown pop-up:
its inflectional category pop-up:
non-lemma:
lemma:
