`$ block release` fails

[Jeremy_Oglesby]

Are we not supposed to be doing this yet, or did I do something wrong?

schedule_conflicts| |master=> block release
building
copying package.json files
installing node modules
[npm] 
[npm] > core-js@3.6.4 postinstall /private/var/folders/lx/d2z19t052vx3m9jb9xpd71nm0000gn/T/airtableBlocks/build/1583468310281/transpiled/user/node_modules/core-js
[npm] > node -e "try{require('./postinstall')}catch(e){}"
[npm] 
[npm] added 77 packages from 133 contributors and audited 672 packages in 17.866s
[npm] 
[npm] 2 packages are looking for funding
[npm]   run `npm fund` for details
[npm] 
[npm] found 0 vulnerabilities
[npm] 
[npm] npm WARN user No description
[npm] npm WARN user No repository field.
[npm] npm WARN user No license field.
[npm] 
transpiling and building frontend bundle
uploading build artifacts
failed to upload build artifacts Error: Failed to upload /var/folders/lx/d2z19t052vx3m9jb9xpd71nm0000gn/T/airtableBlocks/build/1583468310281/build_artifacts/bundle.js
    at /Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/transpiled/src/commands/release.js:673:2744
    at tryCatch (/Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:45:40)
    at Generator.invoke [as _invoke] (/Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:271:22)
    at Generator.prototype.<computed> [as next] (/Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:97:21)
    at tryCatch (/Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:45:40)
    at invoke (/Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:135:20)
    at /Users/JMO/.nvm/versions/node/v13.5.0/lib/node_modules/@airtable/blocks-cli/node_modules/regenerator-runtime/runtime.js:145:13
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
Error: Failed to upload /var/folders/lx/d2z19t052vx3m9jb9xpd71nm0000gn/T/airtableBlocks/build/1583468310281/build_artifacts/bundle.js

[Jeremy_Oglesby]

Well, attempt #2 was successful:

schedule_conflicts| |master=> block release
building
copying package.json files
installing node modules
[npm] 
[npm] > core-js@3.6.4 postinstall /private/var/folders/lx/d2z19t052vx3m9jb9xpd71nm0000gn/T/airtableBlocks/build/1583469021538/transpiled/user/node_modules/core-js
[npm] > node -e "try{require('./postinstall')}catch(e){}"
[npm] 
[npm] added 77 packages from 133 contributors and audited 672 packages in 8.935s
[npm] 
[npm] 2 packages are looking for funding
[npm]   run `npm fund` for details
[npm] 
[npm] found 0 vulnerabilities
[npm] 
[npm] npm WARN user No description
[npm] npm WARN user No repository field.
[npm] npm WARN user No license field.
[npm] 
transpiling and building frontend bundle
uploading build artifacts
releasing
✅ successfully released block!

… however, my released block will not load, whereas I had no issues in development/testing:

[Emma_Yeap]

block release should be working, sorry about this. To help debug, could you share:

• Version of @airtable/blocks your block uses (in package.json)
• Version of the CLI you’re using (block --version)
• The console error from your released block (unlike development, it’s not rendered in the block - but it’ll still be in the browser console)

Thanks!

[Jeremy_Oglesby]

Thanks, @Emma_Yeap

package.json:

{
    "dependencies": {
        "@airtable/blocks": "0.0.42",
        "react": "^16.9.0",
        "react-dom": "^16.9.0"
    },
    "devDependencies": {
        "eslint": "^6.3.0",
        "eslint-plugin-react": "^7.14.3",
        "eslint-plugin-react-hooks": "^2.0.1"
    },
    "scripts": {
        "lint": "eslint frontend"
    }
}

---

$ schedule_conflicts| |master=> block --version
0.0.44

---

[Emma_Yeap]

Thanks for sharing that! Your SDK and CLI versions look good.

The console error suggests your block’s code was uploaded successfully, but has a runtime error due to calling .filter on null instead of an array. Would you be able to share the code there?

One gotcha with releasing blocks: the block installation you see in development has different GlobalConfig to the released block installation you see in your base (so changes you make while testing don’t affect your released block installations). Not sure without seeing the code, but if you were relying on a certain value of globalConfig being an array, that would cause this error where it works in development but not in release.

[Jeremy_Oglesby]

I am using globalConfig to store a <ViewPickerSynced .. /> selection.

And I call .filter on the records queried from that view.

I’m guessing this means the block is trying to initialize with a null key in the globalConfig for my view, and so the records are never being queried?

I think I get the problem, but I’m not sure I see how to fix it. Do I need to guard against null in the query, prior to filtering (as in, provide an empty array instead of null)?

[Jeremy_Oglesby]

function ScheduleConflictsBlock() {
    const base = useBase();
    const globalConfig = useGlobalConfig();

    // We want to render the list of records in this table.
    const appointmentsTable = base.getTableByName(BaseSpecificNames.APPOINTMENTS_TABLE);
    const peopleTable = base.getTableByName(BaseSpecificNames.PEOPLE_TABLE);

    // The view ID is stored in globalConfig using ViewPickerSynced.
    const viewId = globalConfig.get(GlobalConfigKeys.VIEW_ID);
>>>>const appointmentsView = appointmentsTable.getViewByIdIfExists(viewId);

    const people = useRecords(peopleTable);
>>>>const appointments = useRecords(appointmentsView);

    // Get a person's linked appointments and match them with the person
    const peopleAppointments = people.map(person => {
        const personLinkedAppointments = person.getCellValue(BaseSpecificNames.PEOPLE_APPOINTMENTS_LINK_FIELD);
        const appointmentIds = personLinkedAppointments.map(a => a.id);

>>>>>>>>const personAppointments = appointments.filter(a => appointmentIds.includes(a.id));

        const personAppntmntsObj = {
            person: person.getCellValue(BaseSpecificNames.PEOPLE_NAME_FIELD),
            appointments: personAppointments
        };
        return personAppntmntsObj;
    });
...

[Emma_Yeap · Accepted solution]

Thanks for sharing the code!

I’m guessing this means the block is trying to initialize with a null key in the globalConfig for my view, and so the records are never being queried?

Yes, this sounds correct - globalConfig returns undefined for a key with no value, getViewByIdIfExists(undefined) returns null, then useRecords(null) returns null.

I think I get the problem, but I’m not sure I see how to fix it. Do I need to guard against null in the query, prior to filtering (as in, provide an empty array instead of null)?

Yup. The pattern our examples follow is: check that the models the block relies on exist and only render the “result” component if so. For example, in the simple chart example, the chart is only rendered if data exists - {data && ...}

You could also fix the problem locally by checking that appointments is not null when you try to filter it - const personAppointments = appointments ? appointments.filter(...) : [] . This is a quicker fix, but more brittle.

For ease of testing your fix - you can actually clear globalConfig in development mode. See the “GlobalConfig” tab below the development block installation.

Hope this helps you get your block working!

[Jeremy_Oglesby]

Thank you @Emma_Yeap! Super helpful!

I applied the quick fix and that got it up and running successfully. I’ll look into refactoring such that I can conditionally render the results. As my code is now, I don’t think it’s possible for me to do that. Thank you for helping me to realize that architectural mistake!