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

Transition to MastoAPI: user data #1925

Closed
hj wants to merge 0 commits from gitlab-mr-iid-655 into develop
pull from: gitlab-mr-iid-655
merge into: pleroma:develop
Conversation 30 Commits - Files changed -
hj commented 2019-03-07 22:42:38 +00:00
Owner
Copy link
  • Added support for fetching relationship via API.
  • Made code more resilient to missing data - mergeOrAdd now completely ignores null values.
  • Optimized some things that were doing same thing twice, sometimes badly.
  • Fetches user posts and user media via MastoAPI
- Added support for fetching relationship via API. - Made code more resilient to missing data - mergeOrAdd now completely ignores `null` values. - Optimized some things that were doing same thing twice, sometimes badly. - Fetches user posts and user media via MastoAPI
shpuld commented 2019-03-10 20:51:17 +00:00
Owner
Copy link

don't like this rename, it's not a find so why call it a find? userById tells exactly what it returns and using what data

don't like this rename, it's not a find so why call it a find? userById tells exactly what it returns and using what data
shpuld commented 2019-03-10 20:52:20 +00:00
Owner
Copy link

skip

skip
shpuld commented 2019-03-10 20:53:12 +00:00
Owner
Copy link

would prefer filter instead of reject/omit when possible, and when working with objects, filter with identity func would work just as well

would prefer filter instead of reject/omit when possible, and when working with objects, filter with identity func would work just as well
shpuld commented 2019-03-10 20:53:20 +00:00
Owner
Copy link

'used'

'used'
shpuld commented 2019-03-10 20:55:26 +00:00
Owner
Copy link

unused args, also I can't say for sure but I have a feeling that we might run into bugs here, this part has been bug prone and now it works differently again

unused args, also I can't say for sure but I have a feeling that we might run into bugs here, this part has been bug prone and now it works differently again
shpuld commented 2019-03-10 20:56:18 +00:00
Owner
Copy link

iid?

iid?
hj commented 2019-03-10 21:08:55 +00:00
Author
Owner
Copy link

yeah, this test basically needs a rewrite i think, i'll look into it.

yeah, this test basically needs a rewrite i think, i'll look into it.
hj commented 2019-03-10 21:09:14 +00:00
Author
Owner
Copy link

sure

sure
hj commented 2019-03-10 21:09:43 +00:00
Author
Owner
Copy link

whoops

whoops
hj commented 2019-03-10 21:11:15 +00:00
Author
Owner
Copy link

yeah, the whole user profile might as well changed somewhat. A lot of trouble comes from the whole id/name discrepancy. I'll remove unused bugs.

yeah, the whole user profile might as well changed somewhat. A lot of trouble comes from the whole id/name discrepancy. I'll remove unused bugs.
hj commented 2019-03-10 21:11:29 +00:00
Author
Owner
Copy link

whoops

whoops
hj commented 2019-03-10 21:13:59 +00:00
Author
Owner
Copy link

the thing is, userById and userByName been doing nearly same thing except using worse way (iterating over array instead of using a map), Since we store users both by screen name (locals only) and by id (everyone) the only thing we're missing here is case insensitivity, though that could be fixed easily.

the thing is, `userById` and `userByName` been doing nearly same thing except using worse way (iterating over array instead of using a map), Since we store users both by screen name (locals only) and by id (everyone) the only thing we're missing here is case insensitivity, though that could be fixed easily.
hj commented 2019-03-10 23:57:01 +00:00
Author
Owner
Copy link

Well... since it's an object, the alternative is...

      Object.entries(item)
        .filter(([k, v]) => v !== null)
        .reduce((acc, [k, v]) => {
          acc[k] = v
          return acc
        }, {}))

as much as i don't like using lodash, you can't do just {}.filter([k,v] => ...)

Well... since it's an object, the alternative is... ```js Object.entries(item) .filter(([k, v]) => v !== null) .reduce((acc, [k, v]) => { acc[k] = v return acc }, {})) ``` as much as i don't like using lodash, you can't do just `{}.filter([k,v] => ...)`
hj commented 2019-03-11 00:19:51 +00:00
Author
Owner
Copy link

actually much easier than i thought

actually much easier than i thought
hj commented 2019-03-11 00:21:52 +00:00
Author
Owner
Copy link

i've made it case insensitive by downcasting all the time.

i'm open for suggestions for a better name. It searches usersObject if there's a user with needed screen name (only used for local users, so we can query the object as well) or id

i've made it case insensitive by downcasting all the time. i'm open for suggestions for a better name. It searches `usersObject` if there's a user with needed screen name (only used for local users, so we can query the object as well) or id
shpuld commented 2019-03-11 06:47:38 +00:00
Owner
Copy link

ah nevermind that then, I misunderstood what the original did

now I'm just confused why are we omitting any props from anything? seems pretty useless

ah nevermind that then, I misunderstood what the original did now I'm just confused why are we omitting any props from anything? seems pretty useless
shpuld commented 2019-03-11 06:51:22 +00:00
Owner
Copy link

oh it does both now? do we have a map of users with ids and names in the keys now? that's a bit confusing but ok

oh it does both now? do we have a map of users with ids and names in the keys now? that's a bit confusing but ok
hj commented 2019-03-11 09:29:10 +00:00
Author
Owner
Copy link

It did for a long while, only storing local users this way though.

It did for a long while, only storing local users this way though.
hj commented 2019-03-11 09:37:08 +00:00
Author
Owner
Copy link

This is for better compatibility with normalizer and inconsistent data, really. Though there is another way, at least i see it now.

This is the place where we update our user and, in other place, status is updated similar way. The problem is, if you had object like { a: 1 } and merge { a: null } into it it will become { a: null } which basically removes existing data and often causes things to "blink".

Another option would be getting rid of the nulls, which is replacing following: null //missing in MastoAPI with //following (missing in MastoAPI) and so on.

This is for better compatibility with normalizer and inconsistent data, really. Though there is another way, at least i see it now. This is the place where we update our user and, in other place, status is updated similar way. The problem is, if you had object like `{ a: 1 }` and merge `{ a: null }` into it it will become `{ a: null }` which basically removes existing data and often causes things to "blink". Another option would be getting rid of the nulls, which is replacing `following: null //missing in MastoAPI` with `//following (missing in MastoAPI)` and so on.
hj commented 2019-03-11 09:43:49 +00:00
Author
Owner
Copy link

i think I'll do just that instead.

i think I'll do just that instead.
lambadalambda commented 2019-03-11 14:22:20 +00:00
Owner
Copy link

pleroma/pleroma#4308

https://git.pleroma.social/pleroma/pleroma/pulls/4308
lambadalambda commented 2019-03-11 14:23:06 +00:00
Owner
Copy link

looks fine overall but readability could profit a lot from using async / await instead of promise chains.

looks fine overall but readability could profit a lot from using async / await instead of promise chains.
hj commented 2019-03-11 20:58:57 +00:00
Author
Owner
Copy link

Yeah, i'm just not entirely used to async/await just yet. I hope you're ok with this MR not getting a refactor for it.

Yeah, i'm just not entirely used to async/await just yet. I hope you're ok with this MR not getting a refactor for it.
hj commented 2019-03-11 21:00:25 +00:00
Author
Owner
Copy link

Once that's merged it I can test it and then update it. As we all know this spot is very bug-prone already so I really don't want to do blind fixes there - much more work.

Once that's merged it I can test it and then update it. As we all know this spot is very bug-prone already so I really don't want to do blind fixes there - much more work.
hj commented 2019-03-11 21:09:05 +00:00
Author
Owner
Copy link

i did it.

i did it.
lambadalambda commented 2019-03-12 09:34:52 +00:00
Owner
Copy link

sure, we can refactor lator.

sure, we can refactor lator.
tae commented 2019-03-12 18:56:02 +00:00
Member
Copy link

property names under relationship are slightly different.

  • relationship.follows_you => relationship.followed_by
  • relationship.statusnet_blocking => relationship.blocking
  • relationship.muted => relationship.muting

also, we need to support the following property.

output.following => relationship.following

property names under `relationship` are slightly different. - `relationship.follows_you` => `relationship.followed_by` - `relationship.statusnet_blocking` => `relationship.blocking` - `relationship.muted` => `relationship.muting` also, we need to support the `following` property. `output.following` => `relationship.following`
hj commented 2019-03-12 19:01:15 +00:00
Author
Owner
Copy link

thanks, i sorta gave up on this part since it was my suggestion to add this exact block temporarily until we add /relationships support... which this MR adds since BE's MR didn't work for me initially.

thanks, i sorta gave up on this part since it was my suggestion to add this exact block temporarily until we add `/relationships` support... which this MR adds since BE's MR didn't work for me initially.
lambadalambda commented 2019-03-15 13:08:10 +00:00
Owner
Copy link

So what is missing to get this in? everything else is depending on it.

So what is missing to get this in? everything else is depending on it.
hj commented 2019-03-15 13:14:37 +00:00
Author
Owner
Copy link

Nothing, i was mostly just testing it. Luckily i did find some bugs and fixed them.

Nothing, i was mostly just testing it. Luckily i did find some bugs and fixed them.

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
4 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!1925
No description provided.