starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00

[GH-ISSUE #492] Show user avatars in User list #181

New issue

Open

opened 2026-02-27 08:15:43 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 08:15:43 +03:00

Owner

Originally created by @pixelrazor on GitHub (Mar 22, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/492

Can leverage the avatar component from #407

Originally created by @pixelrazor on GitHub (Mar 22, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/492 Can leverage the avatar component from #407

kerem added the

enhancement

frontend

labels

2026-02-27 08:15:43 +03:00

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 23, 2023):

Some things to think about:

Caching (to avoid re-fetching all the users' avatars every time)
Keyed events in the avatar agent, with the username? We don't want to re-fetch all the users' avatars anytime a single one changes.

@nitnelave commented on GitHub (Mar 23, 2023): Some things to think about: - Caching (to avoid re-fetching all the users' avatars every time) - Keyed events in the avatar agent, with the username? We don't want to re-fetch all the users' avatars anytime a single one changes.

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@pixelrazor commented on GitHub (Mar 23, 2023):

With rrespect those concerns, I'm leaning towards the ffollowing solution:

return avatar in GetUserDetail
Storing the user detail list in global state (whether that be Context or we end up using a lib like yewdux)

@pixelrazor commented on GitHub (Mar 23, 2023): With rrespect those concerns, I'm leaning towards the ffollowing solution: - return avatar in GetUserDetail - Storing the user detail list in global state (whether that be Context or we end up using a lib like yewdux)

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 23, 2023):

We could store the avatar in the agent: actually, you could move the request from the avatar display to the agent, and the agent would call you back with the avatar, either from cache or from asking the server.

@nitnelave commented on GitHub (Mar 23, 2023): We could store the avatar in the agent: actually, you could move the request from the avatar display to the agent, and the agent would call you back with the avatar, either from cache or from asking the server.

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@pixelrazor commented on GitHub (Mar 23, 2023):

Well this is going to be multiple avatars, multiple users. I have an initial impl i'll throw up as a draft that loads them after page/table load - while t his is the simpler approach with less changes, i also like it because the initial table and isn't blocked on waiting for all the avatars (a potentially big payload if it's included in the main get of all the users). Anytime you navigate away from the users page, it will refresh when you go back to it anyways, so i don't see a big benefit from adding the complexity here personally.

If we can really justify the larger changes, i'd probably nuke the agent (the Context agents were actually removed, and context/hooks are the preferred way now) and write a component to handle that state and provide it through context or from some third party state lib

@pixelrazor commented on GitHub (Mar 23, 2023): Well this is going to be multiple avatars, multiple users. I have an initial impl i'll throw up as a draft that loads them after page/table load - while t his is the simpler approach with less changes, i also like it because the initial table and isn't blocked on waiting for all the avatars (a potentially big payload if it's included in the main get of all the users). Anytime you navigate away from the users page, it will refresh when you go back to it anyways, so i don't see a big benefit from adding the complexity here personally. If we can really justify the larger changes, i'd probably nuke the agent (the Context agents were actually removed, and context/hooks are the preferred way now) and write a component to handle that state and provide it through context or from some third party state lib

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 23, 2023):

Right, but the agent can have a hash map of the avatars, queried by username.
I was thinking that the user table would just instantiate the avatar components, which would request the avatar from the agent (maybe with some queueing/grouping if it makes sense? In a future update). The Avatar component could then use the suspense API from yew to render a placeholder, and then get called back by the agent when the image is received.
That's also not blocking the user table.

@nitnelave commented on GitHub (Mar 23, 2023): Right, but the agent can have a hash map of the avatars, queried by username. I was thinking that the user table would just instantiate the avatar components, which would request the avatar from the agent (maybe with some queueing/grouping if it makes sense? In a future update). The Avatar component could then use the suspense API from yew to render a placeholder, and then get called back by the agent when the image is received. That's also not blocking the user table.

kerem commented

2026-02-27 08:15:44 +03:00

Author

Owner

@pixelrazor commented on GitHub (Mar 23, 2023):

I think i'm convinced enough. Also of note, agents are now called Workers in yew-agent 0.2.0

@pixelrazor commented on GitHub (Mar 23, 2023): I think i'm convinced enough. Also of note, agents are now called Workers in yew-agent 0.2.0

kerem referenced this issue

2026-02-27 08:18:07 +03:00

[PR #181] [MERGED] ldap: add support for memberOf attribute #594