Add support for parsing layouts #370
Conversation
| componentTree: ComponentState[]; | ||
| cssImports: string[]; | ||
| filepath: string; | ||
| export type PageState = LayoutMetadata & { |
There was a problem hiding this comment.
Admittedly, this is a bit pedantic, but I think we need to be careful about how we set up the typing relationship between Static Pages, Entity Pages, and Layouts. If we're not careful, people can start conflating things (e.g. a Layout is a Static Page).
Having PageState = LayoutMetadata & { ... } sets up a relationship where a PageState "is a" (or at least "contains a") Layout. That makes me a bit nervous. It just so happens that a Layout and a Page share very similar structure, but the two serve different purposes. We want to re-use typings and do composition of types. But, the way that we compose those types does establish these sort of "is a" relationships.
Here's one half-baked idea:
export type ComponentLayout = {
componentTree: ConmponentState[]
}
export type FileMetadata = {
cssImports: string[],
filepath: string;
}
export type LayoutMetadata = {
layout: ComponentLayout,
metadata: FileMetadata
}
export type PageState = {
layout: ComponentLayout,
metadata: FileMetadata,
pagesJS?: PagesJSState
}
That is a very rough idea, we can't implement just that since we already have a FileMetadata. I think one of the key ideas is the differentiation between a Component Layout (a pre-selected set of Components) and a Layout File. A PageState will always have a Component Layout. If a PageState is initially sourced from a Layout File, there can be drift as time goes on. The PageState may keep the same Component layout, but a developer could decide to style those Components differently, changing the cssImports so they no longer match the original LayoutMetadata.
There was a problem hiding this comment.
I was under the impression that we wanted pages to exactly mirror layouts and that we'd always want to keep them in sync so that a layout and a non-PagesJS page would always be interchangeable. But the distinction you're making makes sense. For now, to be on the safe side I've removed the coupling between PageState and LayoutMetadata so the types are independent. It'll take a little more thought to see what the best way is to relate the types safely and coherently like in your example
There was a problem hiding this comment.
Okay, let's keep them independent for now. We can punt on ironing out the type hierarchy. I will make an item for that.
| }; | ||
| } | ||
|
|
||
| private constructRecordsFromSourceFile<SourceFile, SuccessData>( |
There was a problem hiding this comment.
@oshi97, this method feels a bit confusing to me, especially in it's return type. I wonder if there's a better way to consolidate this logic between Layouts & Pages.
There was a problem hiding this comment.
renamed to separateErrorAndSuccessResults! Not sure about these names but I think they're ok for now
| ); | ||
| } | ||
|
|
||
| private initNameToSourceFile<SourceFile>( |
There was a problem hiding this comment.
@oshi97, for this method, I think all we need is a more intuitive name.
There was a problem hiding this comment.
renamed to createFilenameMapping!
| this.layoutNameToLayoutFile = this.initLayoutNameToLayoutFile(); | ||
| } | ||
|
|
||
| getLayoutNameToLayoutState() { |
There was a problem hiding this comment.
Could we add a return type signature here?
## Features - We've introduced the concept of Page Layouts (or Layouts) to Studio. A Page Layout is a pre-prescribed set of Components that you can apply to a Page. By default, Layouts live in the `src/layouts` directory. In the UI, a Layout can be applied via the "Insert" button. (#370, #367, #375) - There is now improved UX for creating or editing an Entity Page's Stream Scope. Instead of being raw inputs, the fields for Entity Ids, Entity Types, and Saved Filters are now drop-downs with the relevant options populated from the account. (#380) ## Changes - Repeaters and Modules have been officially deprecated and removed from Studio. (#369)
## Features - We've introduced the concept of Page Layouts (or Layouts) to Studio. A Page Layout is a pre-prescribed set of Components that you can apply to a Page. By default, Layouts live in the `src/layouts` directory. In the UI, a Layout can be applied via the "Insert" button. (#370, #367, #375) - There is now improved UX for creating or editing an Entity Page's Stream Scope. Instead of being raw inputs, the fields for Entity Ids, Entity Types, and Saved Filters are now drop-downs with the relevant options populated from the account. (#380) ## Changes - Repeaters and Modules have been officially deprecated and removed from Studio. (#369)
This PR creates a new
LayoutMetadatadomain model to represent a Layout. A newLayoutFilesourcefile is added for parsing layouts. Currently, we only support layouts in the top-level of thesrc/layoutsdirectory (i.e. no nested folders). Any nested directories for both layout and pages will now be ignored.I opted not to create a model for layouts with errors because, for now, this information is not anticipated to be used in the UI. Like components, we will not be showing layouts with errors in the Add Element menu. Unlike components, there is nowhere else in the UI an errored layout would surface, since it's not a "component" that would be part of a component tree. The parsing error is still logged in the terminal though.
J=SLAP-2929
TEST=auto
Since much of the logic is shared between parsing a page and parsing a layout, I moved the tests for parsing a component tree into a separate file so only sourcefile-specific tests remain in
PageFile.getPageState.test.tsx.