pleroma-fe issueshttps://git.pleroma.social/pleroma/pleroma-fe/-/issues2023-04-03T19:59:28Zhttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/1247Inclusive language: "NSFW" -> sensitive2023-04-03T19:59:28ZtusooaInclusive language: "NSFW" -> sensitive<!--
please use one of the templates if applicable, otherwise - type out here
in free-form
-->
People mark things as sensitive for different reasons, e.g. food, trauma, politics, spoiler. Not just sex.<!--
please use one of the templates if applicable, otherwise - type out here
in free-form
-->
People mark things as sensitive for different reasons, e.g. food, trauma, politics, spoiler. Not just sex.https://git.pleroma.social/pleroma/pleroma-fe/-/issues/1152addNewStatuses efficiency2023-04-03T20:21:18ZtusooaaddNewStatuses efficiencyhttps://git.pleroma.social/pleroma/pleroma-fe/-/blob/develop/src/modules/statuses.js#L156
this function calls `sortTimeline(timelineObject)` which contains a simple sort. I am skeptical about the efficiency of this. could we maybe bench...https://git.pleroma.social/pleroma/pleroma-fe/-/blob/develop/src/modules/statuses.js#L156
this function calls `sortTimeline(timelineObject)` which contains a simple sort. I am skeptical about the efficiency of this. could we maybe benchmark this?
see also https://stackoverflow.com/questions/1344500/efficient-way-to-insert-a-number-into-a-sorted-array-of-numbershttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/1070Change "public timeline" to something more understandable2023-04-03T20:51:53Zrinpatchrin+pleroma@patch.cxChange "public timeline" to something more understandable"Public timeline" does not really indicate what posts are there, one could easily assume it's a timeline of all public posts. Instead we should use "Local timeline" (proposed by me, what mastodon uses), "Instance timeline" (proposed by @..."Public timeline" does not really indicate what posts are there, one could easily assume it's a timeline of all public posts. Instead we should use "Local timeline" (proposed by me, what mastodon uses), "Instance timeline" (proposed by @shpuld) or maybe just have the timeline called the name of the instance (proposed by @feld, wouldn't play nicely with every instance name though)
Arose from the following irc discussion:
```
2021-03-04 19:38:03 @rinpatch does "public timeline" actually make sense to someone who hasn't used pleroma before?
2021-03-04 19:38:46 @rinpatch I tried directly translating it to russian and it just didn't make sense, so I looked at what masto does, and they just name it "local timeline" in all localizations, which seems to make more sense to me
2021-03-04 19:41:45 feld rinpatch: i prefer when that timeline is named after the actual instance
2021-03-04 19:41:59 feld https://irc.feld.me/uploads/8708dcd99c2fc347/image.png
2021-03-04 19:42:09 @rinpatch also an option
2021-03-04 19:42:26 feld some instances have names that make that less palatable though
2021-03-04 19:42:49 Shpuld in my timeline-menu branch I also made "Timeline" to "Home Timeline" for less confusion
<...>
2021-03-04 19:51:09 Shpuld btw for public timeline, maybe calling it instance timeline makes sense
2021-03-04 19:51:28 @lanodan Yeah but for newcomers wtf is an instance
2021-03-04 19:54:50 Shpuld in retrospect mastodon naming for this stuff is better, feels like only raesons for our current terminology for timelines is a) familiar for old users b) different than mastodon
2021-03-04 19:55:39 @lanodan "Home / Local / Federated" right?
2021-03-04 19:55:47 Shpuld I'm not sure if either of those are particularly good reasons
2021-03-04 19:55:56 Shpuld yeah
2021-03-04 20:03:15 @rinpatch Shpuld,feld,lanodan: so, should we just change it to "Local timeline" or "Instance timeline" right now, or is it something that requires opening a discussion issue?
2021-03-04 20:03:31 Shpuld probably requires discussion
<...>
2021-03-04 20:03:49 @lanodan Both work well in french btw
2021-03-04 20:05:49 @rinpatch instance timeline wouldn't work well in russian, I will stick to local timeline regardless of the source string
```https://git.pleroma.social/pleroma/pleroma-fe/-/issues/941Refactoring: Notification and Status2023-04-03T22:05:40ZHJRefactoring: Notification and StatusHere's a proposition to refactor some parts of our code to improve clarity, remove the duplication and reduce overall complexity. This would also allow easier creation of proper Mentions/Interactions column.
**Problem**: Notification ei...Here's a proposition to refactor some parts of our code to improve clarity, remove the duplication and reduce overall complexity. This would also allow easier creation of proper Mentions/Interactions column.
**Problem**: Notification either renders a Status or tries to mimic how status looks for non-mentions and uses StatusContent. This is a bit confusing and the "mimics the Status" feels wrong, not to mention causes problems with CSS.
**Proposed solution**: unify both into an Activity component, which is basically what both Notification and Status have in common - avatar, name/info, timestamp. It would render StatusContent for activities that warrant it (status, mention, favorite, repeat, emoji) or other content for non-status-based activities (follow, move). It would also render the action bar (reply, rt, fav, emoji, dots) if activity is interactive (mention, status).
This would basically be a component that could render both MastoAPI's Notification and Status.
**What this proposal does not solve/pitfalls**: probably doesn't really makes it easier to make statuses expandable in Notification column/Interactions Timeline since that's a Conversation component and expansion feels like part of Timeline's responsibility, not statuses'https://git.pleroma.social/pleroma/pleroma-fe/-/issues/902the "Valid Until" under OAuth tokens should be "Created at"2023-04-03T22:14:44ZGhost Userthe "Valid Until" under OAuth tokens should be "Created at"it's and expiration date for initial connection, which is equal [5 minutes](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/mfa/token.ex#L15)
![oauth_valid_until](/uploads/2ebd2d8f24e97ca251c4d80051d7899b/oauth_val...it's and expiration date for initial connection, which is equal [5 minutes](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/mfa/token.ex#L15)
![oauth_valid_until](/uploads/2ebd2d8f24e97ca251c4d80051d7899b/oauth_valid_until.png)https://git.pleroma.social/pleroma/pleroma-fe/-/issues/871Let's come up with a standardized way to store auth2023-04-03T22:18:33ZAlex GleasonLet's come up with a standardized way to store authCorresponding Soapbox FE issue: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/148
With swappable frontends being a thing, and with at least 4 in active development, I think it would be ideal to make the process of switching fronten...Corresponding Soapbox FE issue: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/148
With swappable frontends being a thing, and with at least 4 in active development, I think it would be ideal to make the process of switching frontends seamless for the users. As it stands, moving to a different frontend requires all users to log in again on the new frontend. This is inconvenient and could cause loss of traffic on larger servers.
I believe this is something all frontends will care about, since it's just as valid to switch from Soapbox FE into Pleroma FE, or between any other two frontends.
When I was coding the auth side of Soapbox FE, I made an attempt to mimic Pleroma FE's auth for compatibility, but ran into a few roadblocks:
1. It does not store OAuth expiration info or refresh tokens, making it seemingly impossible(?) for the frontend to handle Pleroma's auto-expire feature. In Soapbox FE I store the entire HTTP response from creating the tokens so we can deal with that.
2. It seems somewhat library specific. It's saved under a key called `vuex-lz` (is this Vue specific?) and seems to use the library localforage, which is another dependency I haven't used. In Soapbox FE I'm storing auth inside of native localStorage.
## Pleroma FE auth
![Screenshot_from_2020-06-07_15-00-24](/uploads/994fc613babb58f8937aa88287b96e38/Screenshot_from_2020-06-07_15-00-24.png)
## Soapbox FE auth
![Screenshot_from_2020-06-19_10-15-20](/uploads/05627ed1845add49ca088c9026032406/Screenshot_from_2020-06-19_10-15-20.png)
(Don't worry, these aren't live tokens)
The actual file where auth is handled in Soapbox FE can be found here: https://gitlab.com/soapbox-pub/soapbox-fe/-/blob/develop/app/soapbox/reducers/auth.js
It uses two keys in localStorage:
- `soapbox:auth:app`
- `soapbox:auth:user`
Anyway I just wanted to open an issue here to get started thinking about this problem. I don't have a proposal or anything, but I think it will probably be something we'll want to figure out.
If we decide we can't come up with a standardized way, then I'll probably be adding an *Authmogrifier* to Soapbox FE to handle all the auth from different frontends. :smile:https://git.pleroma.social/pleroma/pleroma-fe/-/issues/859Move towards global events2023-04-03T22:29:19ZHJMove towards global eventsFor certain things, like keeping modal state or async component ready state, the "Settings saved!" thing using vuex state seems to be a bit of an overkill. Using global events and local state feels more appropriate and possibly cheaper.
...For certain things, like keeping modal state or async component ready state, the "Settings saved!" thing using vuex state seems to be a bit of an overkill. Using global events and local state feels more appropriate and possibly cheaper.
The idea is to do something like this:
```
// component a
this.$root.$emit('someGlobalEvent') // emit global event
// component b
this.$root.$on('someGlobalEvent', () => poop()) // do something
```
real world example would be replacing `currentSaveStateNotice` in `interface.js` with global events `settingsSaved` and `settingsError` (or something with better names)https://git.pleroma.social/pleroma/pleroma-fe/-/issues/831Proposed URL change for user profiles2023-04-03T20:09:47ZxxProposed URL change for user profilesRather than:
```
/user?tab=statuses
/user?tab=followees
/user?tab=followers
/user?tab=media
/user?tab=favorites
```
do this:
```
/user/statuses
/user/following
/user/followers
/user/media
/user/favorites
```Rather than:
```
/user?tab=statuses
/user?tab=followees
/user?tab=followers
/user?tab=media
/user?tab=favorites
```
do this:
```
/user/statuses
/user/following
/user/followers
/user/media
/user/favorites
```https://git.pleroma.social/pleroma/pleroma-fe/-/issues/817Speed up fetching of posts in PleromaFE2023-04-03T22:22:54ZfeldSpeed up fetching of posts in PleromaFE > Currently, it seems to wait for some unrelated endpoints to return first. Might even be possible to do it right at the start without waiting for the config.json to return.
I've observed this too. When you load a user profile, for exa... > Currently, it seems to wait for some unrelated endpoints to return first. Might even be possible to do it right at the start without waiting for the config.json to return.
I've observed this too. When you load a user profile, for example, the first call to `/api/v1/accounts/:id/statuses` is to fetch the pinned posts, and once that completes it seems to fire off a GET to `/api/v1/accounts/:id/statuses` for the profile timeline and the `media_only` timeline.
If we could reduce the user profile timeline to a single API call (one RTT to the database) that would be ideal. Perhaps we could get the BE to ignore `pinned=true` if `max_id` is set as well? This just means the FE could request 20 statuses and receive 20 + pinned, but that shouldn't be a deal breaker.
Additionally it seems like the notifications panel timeline isn't fetched concurrently either.https://git.pleroma.social/pleroma/pleroma-fe/-/issues/804Navigation overhaul2023-04-03T22:07:00ZHJNavigation overhaulCurrent navigational sidebar is obnoxious and only gonna get worse. Collapsing it is a band-aid solution and won't work in the long term (more icons for everything = confusing)
Proposed solution (pay no attention to lack of post form): ...Current navigational sidebar is obnoxious and only gonna get worse. Collapsing it is a band-aid solution and won't work in the long term (more icons for everything = confusing)
Proposed solution (pay no attention to lack of post form):
![newpleroma1](/uploads/6de4cd85b404825fdb1bc359ebbe0a84/newpleroma1.png)
![newpleroma4](/uploads/cfa3130ffd55ecaa61c0186d50415d34/newpleroma4.png)
* Timelines switcher that switches right column between different timelines
* Good idea would be to make entire right column a separate component that contains any timeline selected, this would set some ground work for multi-column support, if we ever decide to implement that
* Non-timeline pages go into user (or burger) menu + logout/administration links
* Next to timeline switcher there should be a "back" button (including on non-tl page and on user page)
* There also should be quick-switch icons to be able to get to home tl, dms, interactions, TWKN and local TL.
There are still some question regarding how user/burger menu will work and how to do some onboarding so that existing users don't get confused by moving stuff into different placeshttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/721Inconsistent naming of statuses/posts2023-04-03T23:06:40Zrinpatchrin+pleroma@patch.cxInconsistent naming of statuses/postsCurrently the English translation names statuses inconsistently. In notification panel they are named "Statuses", however in settings they are mostly named "Posts". We should decide on how to name them and make it consistent.
Speaking o...Currently the English translation names statuses inconsistently. In notification panel they are named "Statuses", however in settings they are mostly named "Posts". We should decide on how to name them and make it consistent.
Speaking of naming, am I the only one who finds it weird that the Status modal says "Submit"? In my experience "Submit" is usually said about a form, but with statuses "Post" is usedhttps://git.pleroma.social/pleroma/pleroma-fe/-/issues/576Add post-persistence global mutation to store2023-04-03T22:25:42ZHJAdd post-persistence global mutation to storeProblem: every time we change something in store persistent state will load old data. This was especially the case in Themes v2 and now it's in MastoAPI registration MR.
Current workaround: check what state is and work with that even if...Problem: every time we change something in store persistent state will load old data. This was especially the case in Themes v2 and now it's in MastoAPI registration MR.
Current workaround: check what state is and work with that even if it's not exactly documented or mentioned in code
Proposed solution: add a "persistent state loaded" type of migration that would tell all vuex modules to check for old stuff and migrate it if needed.https://git.pleroma.social/pleroma/pleroma-fe/-/issues/344Tech Debt: Clean up CSS2021-01-26T18:15:34ZShpuld ShpludsonTech Debt: Clean up CSSCurrently our CSS is a bit all over the place, bad practices are used and some things have so many nested styles refactoring or modifying it is very hard.
My thoughts on some things that could/should be improved:
- Clean up bad practice...Currently our CSS is a bit all over the place, bad practices are used and some things have so many nested styles refactoring or modifying it is very hard.
My thoughts on some things that could/should be improved:
- Clean up bad practices, like using flex over float
- Simplify complex nesting of styles
- Avoid inheriting too many styles from other components (Keep common sense with you: using generic styles like .panel, .panel-heading from app.scss is completely fine, but user-card-content being affected by what happens in user-card is not so fine)
- More clear class naming (status.vue has some very bad examples of this)
OTHER DEVELOPERS: please comment your thoughts on what sort of CSS you think would be optimal for this project and why. Keeping factors in mind such as needing to support the theming engine, readability/maintainability, ease of working.
Any work for this issue should be done in reasonably sized chunks when possible, having merge requests that span the entire application is not preferable. It's also very important to keep an eye on regressions.