Move rootItemId to configuration

[Antonytm]

Is your suggestion related to a problem? Please describe.

I have a question about this part of the code in dictionary-servce-factory.ts:

? new GraphQLDictionaryService({
    endpoint: config.graphQLEndpoint,
    apiKey: config.sitecoreApiKey,
    siteName,
    /*
      The Dictionary Service needs a root item ID in order to fetch dictionary phrases for the current
      app. If your Sitecore instance only has 1 JSS App, you can specify the root item ID here;
      otherwise, the service will attempt to figure out the root item for the current JSS App using GraphQL and app name.
      rootItemId: '{GUID}'
    */
  })

I majorly worked with Next.js implementations and I almost always needed to specify rootItemId.
For a major part of cases, I moved this setting to configuration/environment variables.

I think that it will be convenient to move rootItemId to the configuration. (environment variables)
But that wasn't done for any of the web frameworks. I guess that there is some reason for that that I miss.

What is the reason for avoiding rootItemId in the configuration?

Describe the solution you'd like

I want rootItemId to be present together with other configurable settings: sitecoreApiKey, sitecoreApiHost, jssAppName, etc.

Is there a way to achieve this functionality with exisiting tools?

Yes.

You can write code by yourself. Usually, I change config generation to work with rootItemId in a similar way as with other configurations. (sitecoreApiKey, sitecoreApiHost, etc.)

Additional information

If you are interested in this change, I will be able to implement it.
As it is looks like an easy change. Only the testing for different frameworks may take additional time.

[art-alexeyenko]

@Antonytm this is a fair request, but please let me clarify your usecase a little.
What is your usual site structure? Do you create it via jss deploy app command, manually on Sitecore side, or by using SXA?
I'm asking this because GraphQLDictionaryService usually uses the siteName and ensures the site root is resolved correctly. If it doesn't, there might be a bug.

I think this is one of the reasons rootItemId was not made part of configuration - the resolver used in internal JSS logic should get it for you, as long as your site's root template is /sitecore/templates/Foundation/JavaScript Services/App

[Antonytm]

I faced the inability to resolve the site with just a name a few times. Both times, the structure was about the same: a few sites that were created using SXA. The presence of the ability to set rootItemId made me think that it was by design that for some multisite structures you will need to set it up. That is why I opened a discussion, but not a bug with exact conditions, when it is reproducible.

Sorry, the last time it was a month ago. And, I didn't have the exact setup to check and figure out the conditions on how to reproduce it.
Once the issue will be reproduced, I will update the details.