Codegen generates "split up" schema, causing name collisions in file. Possibly due to layout using tab controls
Closed this issue · 7 comments
First of all, thank you for the great tool you provide with the codegen feature!
For some schemas and types though, the codegen generates "split up" schemas and type definitions.
What I mean by that is that
given a valid schema like
const ZSchema = z.object({
key1: z.string(),
key2: z.string(),
key3: z.string(),
key4: z.string(),
});we instead get
const ZSchema = z.object({
key1: z.string(),
key2: z.string()
});
// continuation of same schema, using same name, causing name collision.
const ZSchema = z.object({
key3: z.string(),
key4: z.string(),
});When I looked at one some of the layouts that generated this kind of corrupt code, I noticed that the split seemed to follow the split between different tab controls in that layout. So in the example above, key 1 and 2 would be visible in one tab, and key 3 and 4 would be visible in the other.
Maybe this is known limitation of the codegen tool, but I thought you might want to know.
I added a screenshot of one of the layouts we had issues with, to avoid any confusion about what I mean by "tabs"
Please note that this is just my guess. I'm not sure that tabs in layouts is the real issue here.
Thanks for this report. The codegen relies entirely on the layout metadata endpoint that FileMaker provides through the Data API, and I have seen some strange behavior from that endpoint in the past but it would be good to see that example. Are you able to send me the layout metadata for your layout? (can exclude field names and other sensitive info, but the structure would be very helpful!)
You can use the library to easily query that endpoint, just use the layoutMetadata method from your generated layout client (if using v4. In v3 is was just metadata)
This is perhaps the easiest case I found:
For important context (I think) the Layout itself is called "Title Server".
So maybe the issue here is that one of the portalMetaData keys has the exact same name?
If so, perhaps I was wrong in describing this issue as a "split up" schema. Maybe the duplication I saw was just schemas for the layout and the portals having the same name?
// output from client.layoutMetadata()
const layoutMetadata = {
fieldMetaData: [
{
name: "Name",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "URL",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "Description",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "remoteType identifier",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "S3 bucket name",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "PrimaryKey",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: true,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: true,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "Environment",
type: "normal",
displayType: "popupMenu",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
valueList: "Title environment",
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "AWS CDN Key",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
{
name: "Server type",
type: "normal",
displayType: "popupMenu",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
valueList: "Title server type",
repetitionStart: 1,
repetitionEnd: 1,
},
],
portalMetaData: {
"Title Server": [
{
name: "Name",
type: "normal",
displayType: "editText",
result: "text",
global: false,
autoEnter: false,
fourDigitYear: false,
maxRepeat: 1,
maxCharacters: 0,
notEmpty: false,
numeric: false,
timeOfDay: false,
repetitionStart: 1,
repetitionEnd: 1,
},
],
},
valueLists: [
{
name: "Title environment",
type: "byField",
values: [],
},
{
name: "Title server type",
type: "customList",
values: [
{
displayValue: "Preview",
value: "Preview",
},
{
displayValue: "Delivery",
value: "Delivery",
},
{
displayValue: "-",
value: "-",
},
{
displayValue: "Preview and Delivery",
value: "Preview and Delivery",
},
],
},
],
};thanks! I'll see if I can replicate this in my test file
@eluce2 Not sure if this helps, but it could be that the portal with seemingly the same name as the layout is this type of portal: https://help.claris.com/archive/help/18/fmp/en/index.html#page/FMP_Help/creating-portals-master-detail.html
That seems to be the case that generated the layout metadata above.
The name of the first schema is the schemaName that you provide in the fmschema.config.mjs file. I don't believe the actual layout name is used in the codegen flow at all. Are you able to resolve this name conflict by either renaming your porta on the layout, or changing the name in the config file?
Ok, I see! Yes I confirmed now using another name in the fmschema.config.mjs works, but to automate this and have it work for new layouts in the future we would need to do the layout meta calls ourselves to even know if we should change the the original name or not (if we only want to change when needed).
I guess we could pre- or postfix every layout name before we use it as schemaName in fmschema.config.mjs to avoid conflicts that way. That would work fine (ignoring any aesthetic considerations :D )
Our flow is that we dynamically create fmschema.config.mjs from the response of GET {{BASE_URL}}/{{DATABASE_NAME}}/layouts/
I'm thinking a pre- or postfix of the generated Portal zodtype names (when needed, since I assume you would have access to both config schemaName and the metadata portal name at the same time when generating the schemas ) on your side could solve it too, but I understand that it's not worth the extra effort and complexity for this edge-case!
Thank you for all the help! Much appreciated! 🥇
Another really good option is to name your portal objects on the layout something unique. Ideally this layout is only used for the data API, so you don't have to make it the table name. Instead, make it something very specific to the relationship and this will also avoid name conflicts