pleroma/pleroma-fe
0
0
Fork 0
Code Issues 343 Pull requests 27 Projects Releases Packages Wiki Activity

Add Favorites TL to user profile, add some initial support for MastoAPI #1734

Closed
hj wants to merge 0 commits from gitlab-mr-iid-462 into develop
pull from: gitlab-mr-iid-462
merge into: pleroma:develop
Conversation 13 Commits - Files changed -
hj commented 2019-01-12 22:42:40 +00:00
Owner
Copy link

Originally i wanted to just add Favorites timeline and add support for passing timeline object as is instead of using timelineName.
Turns out we also don't have QvitterAPI for it!

Currently this MR strives to change architecture a bit:

Instead of computing various stuff in modules/statuses.js (or users.js or any module, really) and such we instead convert incoming data to some middle format and resolve missing stuff in place. So for example instead of calling fileTypeService.fileType() for every attachment in templates we resolve it once for each attachment in each status when fetching the data. Another example is checking for #nsfw in status.text when adding statuses to timeline, instead check right after fetching.

This should decouple UI and logic code from specific API, light up several modules and allow for mixing and matching different APIs until we completely switch to MastoAPI and deprecate QvitterAPI.

Originally i wanted to just add Favorites timeline ~~and add support for passing timeline object as is instead of using timelineName.~~ Turns out we also don't have QvitterAPI for it! Currently this MR strives to change architecture a bit: Instead of computing various stuff in `modules/statuses.js` (or `users.js` or any module, really) and such we instead convert incoming data to some middle format and resolve missing stuff in place. So for example instead of calling `fileTypeService.fileType()` for every attachment in templates we resolve it once for each attachment in each status when fetching the data. Another example is checking for `#nsfw` in `status.text` when adding statuses to timeline, instead check right after fetching. This should decouple UI and logic code from specific API, light up several modules and allow for mixing and matching different APIs until we completely switch to MastoAPI and deprecate QvitterAPI.
hj commented 2019-01-17 21:05:44 +00:00
Author
Owner
Copy link

remove

remove
hj commented 2019-01-17 21:05:59 +00:00
Author
Owner
Copy link

ah for fucks sake

ah for fucks sake
shpuld commented 2019-01-19 21:57:07 +00:00
Owner
Copy link

Lots of changes and not sure about the reason for everything so hard to review, but at a quick read-through it all looks ok to me

Lots of changes and not sure about the reason for everything so hard to review, but at a quick read-through it all looks ok to me
shpuld commented 2019-01-22 16:04:26 +00:00
Owner
Copy link

should it be there according to the API or not? also is screen name the @ or the visible name?

should it be there according to the API or not? also is screen name the @ or the visible name?
shpuld commented 2019-01-22 16:08:18 +00:00
Owner
Copy link

I really think it would be beneficial to move all test files to the same dir with the source files. Not only will we get rid of ../../../../../../ and also easier to find the test files in a treeview, and it's harder to ignore them when they're right there.

I really think it would be beneficial to move all test files to the same dir with the source files. Not only will we get rid of ../../../../../../ and also easier to find the test files in a treeview, and it's harder to ignore them when they're right there.
shpuld commented 2019-01-22 16:10:01 +00:00
Owner
Copy link

I know there isn't any agreement for it, but what I like to do is have the highest level describe be the function name (nested inside module/functionality/some other arbitrary grouping), makes it super easy to figure out what the test is for.

I know there isn't any agreement for it, but what I like to do is have the highest level describe be the function name (nested inside module/functionality/some other arbitrary grouping), makes it super easy to figure out what the test is for.
shpuld commented 2019-01-22 16:11:19 +00:00
Owner
Copy link

Oh and of course doesn't have to be done here (I hate how all comments are "unresolved" automatically on gitlab), but I would rather use abs paths in the current format instead of ..

Oh and of course doesn't have to be done here (I hate how all comments are "unresolved" automatically on gitlab), but I would rather use abs paths in the current format instead of ..
hj commented 2019-01-22 16:30:06 +00:00
Author
Owner
Copy link

It's only ever used in this one particular place:
image
MastoAPI doesn't provide this and it's a very minor thing IMO, it could be worked around by changing UI to find user via id in usersObject instead of using the data. Not sure if I want to put it into this MR tho.

It's only ever used in this one particular place: ![image](/attachments/34125949-1f1f-4410-8fbb-7c29e5772e57) MastoAPI doesn't provide this and it's a very minor thing IMO, it could be worked around by changing UI to find user via id in `usersObject` instead of using the data. Not sure if I want to put it into this MR tho.
image.png
8.9 KiB
hj commented 2019-01-22 16:32:42 +00:00
Author
Owner
Copy link

Usually highest level is module, it makes it easier to use .only (which i forgot to remove) and .skip to speed tests up when developing/TDDing by only running relevant tests. I'll rename 'statuses' to 'parseStatus' tho.

Usually highest level is module, it makes it easier to use `.only` (which i forgot to remove) and `.skip` to speed tests up when developing/TDDing by only running relevant tests. I'll rename `'statuses'` to `'parseStatus'` tho.
shpuld commented 2019-01-22 16:50:39 +00:00
Owner
Copy link

err, highest and lowest mixed up

err, highest and lowest mixed up
shpuld commented 2019-01-22 16:51:29 +00:00
Owner
Copy link

yeah not crucial at all (considering it was completely missing from pleroma for ages), better to figure it out from the user object when actually redoing the status header later

yeah not crucial at all (considering it was completely missing from pleroma for ages), better to figure it out from the user object when actually redoing the status header later
hj commented 2019-01-22 17:05:42 +00:00
Author
Owner
Copy link

???

Highest is entity_normalizer ("API Entities normalizer")
Then come function parseStatus()
Lowest a bunch of tests that test one major branch in code that handles Qvitter-specific things (parseStatus and others deal with both MastoAPI and QvitterAPI, they all have "common" code for stuff that matches up and two big if branches for differences between APIs including different naming)
and finally, it that test specific things in context.

??? Highest is `entity_normalizer` ("API Entities normalizer") Then come function `parseStatus()` Lowest a bunch of tests that test one major branch in code that handles Qvitter-specific things (`parseStatus` and others deal with both MastoAPI and QvitterAPI, they all have "common" code for stuff that matches up and two big `if` branches for differences between APIs including different naming) and finally, `it` that test specific things in context.
shpuld commented 2019-01-22 17:32:01 +00:00
Owner
Copy link

yeah I got them mixed up don't worry, you got it right, I was thinking in terms of most nested => highest.

describe('module', () => { describe('function', () => { it('blows up', () => {}) }) })

yeah I got them mixed up don't worry, you got it right, I was thinking in terms of most nested => highest. `describe('module', () => { describe('function', () => { it('blows up', () => {}) }) })`

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
BE Request

   
Backlog

   
Better behavior

   
Blocked by deps

   
Bug

   
Code Review

   
Discussion

   
Doing

   
Feature Request / Enhancement

   
In the shining bright future maybe

   
It's complicated

   
MS Edge

   
Mememoon (or other niche browsers)

   
Missing API

   
Missing feature

   
Missing l10n/i18n

   
NL1

Instance Admin Dashboard

  
NL2

Improved Mobile Experience

  
NL4

Improved instance customization and QoL options

  
Need to verify on develop

   
RELEASE BLOCKER

   
Reassign or Close

   
Refactor

   
Regression

   
Safari

   
To Do

   
User story

   
Waiting on godot

   
accessibility

https://git.pleroma.social/pleroma/pleroma-fe/-/snippets/7746

  
better documentation

   
chore

   
confirmed

   
easy ticket

   
incident

Denotes a disruption to IT services and the associated issues require immediate attention

  
l10n update

   
mastoapi

   
mobile

   
needs design

   
needs-info

   
needs-review

   
stupid
No labels
BE Request
Backlog
Better behavior
Blocked by deps
Bug
Code Review
Discussion
Doing
Feature Request / Enhancement
In the shining bright future maybe
It's complicated
MS Edge
Mememoon (or other niche browsers)
Missing API
Missing feature
Missing l10n/i18n
NL1
NL2
NL4
Need to verify on develop
RELEASE BLOCKER
Reassign or Close
Refactor
Regression
Safari
To Do
User story
Waiting on godot
accessibility
better documentation
chore
confirmed
easy ticket
incident
l10n update
mastoapi
mobile
needs design
needs-info
needs-review
stupid
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe!1734
No description provided.