Make mastofe work like all the other frontends

lambadalambda commented

2020-06-28 13:43:04 +00:00

Owner

This came up in pleroma/pleroma#5778. It would be nice if mastofe could work like the other frontends, live on / and be able to log in etc. Rebasing it to / is probably easy, but adding the basics for log in seems harder. Maybe we can pull in some stuff from @alexgleason's soapbox?

This came up in https://git.pleroma.social/pleroma/pleroma/pulls/5778#note_65212. It would be nice if mastofe could work like the other frontends, live on `/` and be able to log in etc. Rebasing it to `/` is probably easy, but adding the basics for log in seems harder. Maybe we can pull in some stuff from @alexgleason's soapbox?

lanodan commented

2020-06-28 23:57:52 +00:00

Owner

Live on / could be possible but wouldn't we need a configurable path instead?

Also login page is the OAuth one.

Live on / could be possible but wouldn't we need a configurable path instead? Also login page is the OAuth one.

alexgleason commented

2020-06-29 01:07:45 +00:00

I'd be willing to help with this. The auth part wasn't the hardest though, the "initial-state" part was. The frontend has a LOT of stuff pulled from the initial state, and the code for it looks something like this:

import { autoPlayGif, showMedia } from '../initial-state';

The problem with this code is it relies on a Mastodon-specific element prerendered in the HTML, and you cannot simply pull it from an endpoint because the load order.

It needs to be converted into code like this:

const mapStateToProps = state => ({
  // We have to ascertain this value from some API endpoint
  // and store it in Redux at some point during load.
  autoPlayGif: state.getIn(['meta', 'autoPlayGif']),
});

@connect(mapStateToProps)
class MyComponent extends React.Component {
  propTypes = {
    autoPlayGif: PropTypes.bool,
  }

  render() {
    // It now becomes a first class prop instead of just an imported variable
    const { autoPlayGif } = this.props;
    // ...
  }
}

Maybe with pleroma/pleroma#5759 it could work without rewiring all the internals. We would instead have to map the prerendered data to the initial_state variables. The user would have to enable this feature for mastofe to work.

I'm pretty amazed you've managed to keep it a "distribution" of glitch-soc so far instead of a fork, but I'm not sure you'll be able to continue doing it that way if you want it to work like a first class frontend.

In mastofe, getting rid of the initial-state would require changing 102 files. This is exactly what I did in Soapbox FE, and it was a huge undertaking:

In a perfect world we could fix this in upstream Mastodon. Also in a perfect world, they'd maintain their frontend in a separate repo.

I'd be willing to help with this. The auth part wasn't the hardest though, the "initial-state" part was. The frontend has a LOT of stuff pulled from the initial state, and the code for it looks something like this: ```js import { autoPlayGif, showMedia } from '../initial-state'; ``` The problem with this code is it relies on a Mastodon-specific element prerendered in the HTML, and you cannot simply pull it from an endpoint because the load order. It needs to be converted into code like this: ```js const mapStateToProps = state => ({ // We have to ascertain this value from some API endpoint // and store it in Redux at some point during load. autoPlayGif: state.getIn(['meta', 'autoPlayGif']), }); @connect(mapStateToProps) class MyComponent extends React.Component { propTypes = { autoPlayGif: PropTypes.bool, } render() { // It now becomes a first class prop instead of just an imported variable const { autoPlayGif } = this.props; // ... } } ``` *Maybe* with pleroma/pleroma#5759 it could work without rewiring all the internals. We would instead have to map the prerendered data to the initial_state variables. The user would have to enable this feature for mastofe to work. I'm pretty amazed you've managed to keep it a "distribution" of glitch-soc so far instead of a fork, but I'm not sure you'll be able to continue doing it that way if you want it to work like a first class frontend. In mastofe, getting rid of the initial-state would require changing 102 files. This is exactly what I did in Soapbox FE, and it was a huge undertaking: ![Screenshot_from_2020-06-28_20-02-18](/attachments/33854924-d2be-43d7-b0ee-2e7448722e10) In a perfect world we could fix this in upstream Mastodon. Also in a perfect world, they'd maintain their frontend in a separate repo.

Screenshot_from_2020-06-28_20-02-18.png

131 KiB

lanodan commented

2020-06-29 01:38:19 +00:00

Owner

initialState in glitch should be much easier to adapt and probably would be only itself to change to fetch an endpoint rather than extract from HTML.

But given that pleromafe has been given similar data-in-HTML I don't think it's much of an issue.

Also it managed to keep being a distribution thanks in part to glitch sock making it simpler and me avoiding to change a lot of files and rather modifying it in the smallest lines possible.

initialState in glitch should be much easier to adapt and probably would be only itself to change to fetch an endpoint rather than extract from HTML. But given that pleromafe has been given similar data-in-HTML I don't think it's much of an issue. Also it managed to keep being a distribution thanks in part to glitch sock making it simpler and me avoiding to change a lot of files and rather modifying it in the smallest lines possible.

alexgleason commented

2020-06-29 01:47:04 +00:00

You'd still have to edit all 102 of those files and use mapStateToProps, there's no way around that unless we preload. It was more complicated than I expected because it changes the behavior of the components when they can't get the initial state immediately. The whole app has to be loaded differently.

lanodan commented

2020-06-29 01:51:19 +00:00

Owner

Well maybe preload would be needed but in no way changing these 102 files is going to work (maybe divided by about two as the vanilla flavour doesn't matter).

Or if it's done it will be with cooperation with glitch-soc, but anyway, I want to be sure of what is actually needed so we could avoid extraneous work.

Well maybe preload would be needed but in no way changing these 102 files is going to work (maybe divided by about two as the vanilla flavour doesn't matter). Or if it's done it will be with cooperation with glitch-soc, but anyway, I want to be sure of what is actually needed so we could avoid extraneous work.

lanodan commented

2020-06-29 02:32:50 +00:00

Owner

Also rebasing on / is quite weird, a usual thing that I get from mastofe users is that they use it on one device but not another and this is likely to be even more the case with ChatMessages (as they're probably not going to be present soon enough).

And right now MastoFE depends on PleromaFE as there is no profile edition and similarly I don't see it being there soon either.

Also rebasing on `/` is quite weird, a usual thing that I get from mastofe users is that they use it on one device but not another and this is likely to be even more the case with ChatMessages (as they're probably not going to be present soon enough). And right now MastoFE depends on PleromaFE as there is no profile edition and similarly I don't see it being there soon either.

alexgleason commented

2020-06-29 02:40:35 +00:00

It's pretty trivial to let it run on any path, you just have to change this:

It could be configurable, but I'm not sure where you'd configure it.

It's pretty trivial to let it run on any path, you just have to change this: ![Screenshot_from_2020-06-28_21-39-26](/attachments/e3feb44e-d9be-467c-9697-9f674c39ec02) It could be configurable, but I'm not sure where you'd configure it.

Screenshot_from_2020-06-28_21-39-26.png

64 KiB

lanodan commented

2020-06-29 03:07:21 +00:00

Owner

There is actually other places where changes would have to be done. For example there is the following commits that are done in our modifications: feab0a424d 805385ff53

There is actually other places where changes would have to be done. For example there is the following commits that are done in our modifications: feab0a424d14902aaeaece35607e970f893e3dca 805385ff539f02c87f914be6188a4314f81046b2

Rows
Columns

Make mastofe work like all the other frontends #81