Using the <nylas-editor-tabs> component

Question and Answers
,
1

I am directly using the component and am wondering why my data isn’t showing up. The UI component renders, and updating the hideEditorTabs attribute works, yet setting the selectedConfiguration, currentUser, and calendars attributes are not working (by the fact that no relevant information is in the ui component). For reference, I am reading the documentation here: Editor Tabs Component - Scheduler UI Components

For instance, to get the configuration object, I run the exact flow of this: Nylas v3 Scheduler API docs | Nylas Docs

Similarily, I run Nylas’ API Reference methods for calendars (which returns an array), and I build a current user hash that matches the description of the editor-tab documentation. One thing I noticed, is that the result of the calendar and configuration requests just return an array and hash respectively, but the documentation seems like the editor-tab needs Calendar[] and Configuration objects. Since these are not what is being returned in Nylas’ own requests… how can I expect to get my component to work without all the extra legwork translating the responses to the plenty of types Nylas wants?

    const schedulerEditorTabs = document.querySelector("nylas-editor-tabs");
    schedulerEditorTabs.schedulerPreviewLink = `${window.location.origin}/?config_id={config.id}`;
    schedulerEditorTabs.calendars = calendars;
    schedulerEditorTabs.mode = "app";
    schedulerEditorTabs.currentUser = user;
    schedulerEditorTabs.hideEditorTabs = ["pageStyles"];
    schedulerEditorTabs.selectedConfiguration = configuration;

Example of where I get the calendars. (Configuration is very similar)

  async fetchCalendars(grantId) {
    let header = {
      'Accept': 'application/json',
      'Content-Type': 'application/json',
      'Authorization': `Bearer PlaceholderAPITOKEN`
    };

    let url = `https://api.us.nylas.com/v3/grants/${grantId}/calendars`;

    return await this.ajax(url, 'GET', { headers: header }).then((response) => {
      return response.data;
    });
  }

I have read all documentation and there seems to be none regarding this component

Also, why is there no scheduler tag on this forum when the scheduler is the least documented api? Seems like devs could benefit from the separation of these entities to see community answers…

2

Hello @sboynton I just created the scheduler tag :slight_smile: thanks a lot for your suggestion…

Regarding your question…I will ask the Scheduler team and will get back to you…

3

Thanks. Most of my implementation deals with the scheduler-editor component, or other components like the <nylas-editor-tabs> component. Would it be possible for me to get in contact with the scheduler team to answer some of my questions?

4

I can ask them to jump into the forums although I cannot guarantee anything :frowning:

1 Like
5

@Blag any update on this issue? Or even more documentation on these components?

6

@sboynton a member of the Scheduler team will jump in to help :wink:

7

Hey @sboynton , thanks for building with Scheduler! I’m the Product Manager for Scheduler - I’d love to know what your use case is to start, so that I might suggest the best way to tackle what you’re trying to achieve.

However off the bat, I can tell you that attributes should be set from the nylas-scheduler-editor component. We are still refining our docs, and I appreciate you bringing up the confusion they’ve caused. Some stuff needs to be trimmmed.

When using the nylas-scheduler-editor attributes, the defaultSchedulerConfigState allows you set set the defaults for most fields when creating a page. This means that for already created pages, you won’t see these changes applied.

The idea behind this is to allow you to preset some settings for your users when they first create a page; some of those settings aren’t accessible through the UI, so it’s very useful if you’re trying to cater an experience.

Passing selectedConfiguration automatically opens an already created page, so be mindful that these attributes won’t necessairly work together.

I’d be happy to learn about your use case and make more suggestions!

10

Thanks @antoine for hopping in. In our specific use case we want to bypass the schedule editor login flow. In other words, we have all the grant information we need to theoretically bypass this user experience, and lead us straight into editing a booking (with the configurationId). However, we have struggled to find documentation that leads us to a working solution. Per my post description above, we decided to try a sub-component of the scheduler to see if we could authenticate that without having the editor’s login flow, but found that was not optimal, so we are back to trying to bypass the scheduler. Are there any suggestions you can give us or places to look that demonstrates this behavior? Thanks

11

@Blag @antoine The biggest frustration of this whole process is that docs have been a moving target when the EOL of the current V2 product is less than a month away and support for V2 ends next week. Our hope was that V3 would turn out to be an improvement over the current product but we are finding it just as frustrating to work with just in different ways. I think there is potential in the product you are developing but I am disappointed in how this transition process has taken place.

Ive never seen a company EOL a product as quickly as you are without any form of support in place when the EOL was announced and documentation constantly shifting.