Landscape: Single-page application rearchitecture

[matildepark]

• The build process for each Landscape app has been consolidated into a single build process for all Landscape apps, using Webpack instead of Gulp. It can be run by using npm run build:dev inside pkg/interface.
• All apps have been migrated into a single application, deduplicating all common UI components across the interface.
• Front-end API, subscription and reducers have been rearchitected into a central location, deduplicated, and permissioned per application (such that within Chat, the API is no longer accessible via window.api and able to send authenticated actions to any app as it likes).
• All custom CSS in each application was deduplicated and centralised in preparation for indigo-react integration.
• ContentType has been added to S3 uploads such that they do not prompt a download window (s3: set Content-Type for uploaded media #2865, Add ContentType to uploaded s3 images (SPA) #2890)
• Links unread counts no longer overlap (Unread Links numbers overlap #2833).
• Publish URL to Groups view has been fixed (Publish: 'Manage this group in the contacts view' is a broken link #2889).
• Third party applications can now add their applications to the home screen by just passing their name, icon URL, and a URL to refer, to %launch; they can also easily mount their endpoints using %file-server, without having to write on-watch boilerplate for handling HTTP requests. More details to come for developers.
• Landscape can optionally be hosted at ~landscape and allow you to slot a static page at the root directory instead.
• Unread counts in title bar now filter out the currently filtered channels, when viewing only a specific group's channels (Unread count doesn't reflect group filter #2897).
• Chat no longer scrolls to top of scrollback if the backlog exceeds 1,000 new messages (webchat freezes/crashes browser when loading huge scrollback #2908).
• In chats, images are sized at a maximum of 250px to prevent scroll jumping on Safari (chat: image load borks scroll position #2883).
• Code blocks now overflow properly and scroll within their container when too wide (Wrapping behavior for code text in input & messages behaves poorly #2829).
• The code and s3 buttons in Chat are now graphically aligned.

cc @liam-fitzgerald

[tacryt-socryp]

LGTM based on my last bit of QA over the past few hours. Godspeed.

[ryjm]

will existing landscape apps still sorta work? and will there be any guidance on how to migrate them? i know, i know, the perils of being on the bleeding edge, but i'd really like to spend more time in hoon and much less in react 😬

[matildepark]

will existing landscape apps still sorta work?

Should be fine.

and will there be any guidance on how to migrate them?

I'm working on it! Just cleaning up create-landscape-app today and tomorrow, and when we OTA (quite soon) I'll write some advice on migration for existing third-party apps.

Essentially instead of your Hoon boilerplate having HTTP request handling etc etc. you just let %file-server handle it, so a lot of boilerplate is not necessary.

You can also go without back-end code entirely if you like; you can just poke %file-server to mount an endpoint to the respective folder in /app and it will mount all the HTML, JS, PNG files in the folder. You also can just poke %launch to add a basic tile with only an image and a destination URL.

The tradeoff is that widget-style tile apps are basically no longer possible without writing it directly into pkg/interface/src/apps/launch.

[ryjm]

will existing landscape apps still sorta work?

Should be fine.

and will there be any guidance on how to migrate them?

I'm working on it! Just cleaning up create-landscape-app today and tomorrow, and when we OTA (quite soon) I'll write some advice on migration for existing third-party apps.

beautiful. i think i forked from a pretty old version of create-landscape-app, but i'm optimistic. the main thing i'm worried about is the boilerplate for the OS1 style interface - for srrs, i ended up porting a lot of the frontend code for publish and tweaking the css, and i'd love to get rid of all the hacky stuff i did there... but i'm hoping that the app will still work while i do that.

[philipcmonk]

Have we tried this on -L copies of real ships? I've found that to be a good way of shaking out OTA bugs.

I copied this into a -L copy of ~wicdev and now my homepage is blank (even after force-refresh). Here's the trace: https://pastebin.com/nrd20pib. I just ran |commit %home and then at the end there you can see me trying a manual :goad %force, but that had no effect except to print an error again. I think file-server is failing to start because something's already bound: "url already bound to [clay-base=/app/landscape public=%.n]".

[matildepark]

Hey! That error (I think) shouldn’t mean anything — I want to ask how you merged it in. If you literally took this branch, you’ll need to compile the JS (npm run build:dev). I’ve tried the OTA case on ~sitden and @loganallenc has tested a few OTA cases today with the last patches he wrote.

[philipcmonk]

You're correct, it works when I do that. Thanks!

The fact that +on-load keeps crashing every time on you :goad %force is bad, because it means that app can't reload. On fusion, this will mean no OTAs will succeed until the on-load succeeds. Not a showstopper for this, but it will need to not crash before fusion goes out.

[matildepark]

It would seem imperative to tackle now, then. @loganallenc @liam-fitzgerald would you mind investigating? It seems like %soto just on-loads every single load.

[liam-fitzgerald]

On it!

[Fang-]

Skimmed the hoon-side changes. Nothing outrageous enough to make me want to fight/hold this off.

[tylershuster]

Is the ~landscape url documentation anywhere? I was just dreaming of this feature yesterday

[matildepark]

I'll try to look into it today and write something up.

[tacryt-socryp]

I don’t think this part has been fully integrated on the front-end yet to function properly. Needs some additional love.

[tylershuster]

If you can point me in the right direction I might try giving it some

[matildepark]

@tylershuster As you can see here you can poke file-server to set the Landscape homepage prefix as a unit of terms (you know, %name etc). When we subscribe to Launch, it should provide that prefix. We don't really specifically reduce it, but we do take it in the initial object wholesale, so we should have access to it inside state.

We would then need to use that and make our router relative to the prefix for Launch. We'd need the back nav to update too.

On top of all this, in our current state this isn't possible because the store will wipe as we navigate and we'll lose track of the prefix. But after #3038 this should be fine?

[ryjm]

The tradeoff is that widget-style tile apps are basically no longer possible without writing it directly into pkg/interface/src/apps/launch.

is this only when you're using file server, or in general? how would you go about porting a custom tile? here's what i had to do get srrs working with a basic tile if it's useful for anyone else: ryjm/srrs@d5ff0ec