-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Node
interface id
field to be configurable.
#3638
Conversation
( +1-ing the desire for this, lots of OSS JS/graphQL tooling takes over |
We'd also need to let the relay-runtime know about that property, as so much hangs on that ID field 😅 |
@maraisr From what I can tell,
|
Just a ripe ol pain, coz in places where there is no id field, relay still tries to normalise like serialising some input arguments and such. I've not looked too close, but would suspect this method to have to implement all of those avenues as well? |
@alunyov has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this! Sorry, we dropped the ball on this PR and did not review it earlier.
The main feedback is that let's try re-using FeatureFlags
for this id
field configuration.
@@ -341,7 +341,7 @@ impl CompilerState { | |||
.any(|sources| !sources.processed.is_empty()) | |||
} | |||
|
|||
fn is_change_safe(&self, sources: &SchemaSources) -> bool { | |||
fn is_change_safe(&self, sources: &SchemaSources, project_config: &ProjectConfig) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add node_interface_id_field
to the compiler_state itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do this, but the config that's used to create the compiler_state is the root config, not the project config, so this seemed challenging to try to move.
@@ -363,7 +363,7 @@ impl CompilerState { | |||
¤t, | |||
&Vec::<(&str, SourceLocationKey)>::new(), | |||
) { | |||
Ok(schema) => schema_change.is_safe(&schema), | |||
Ok(schema) => schema_change.is_safe(&schema, project_config.node_interface_id_field), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then here we can pass self. node_interface_id_field
@@ -843,6 +851,9 @@ struct ConfigFileProject { | |||
|
|||
#[serde(default)] | |||
js_module_format: JsModuleFormat, | |||
|
|||
#[serde(default)] | |||
pub node_interface_id_field: Option<StringKey>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add comment here, and also to the compiler README.md that explains the purpose of this field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think this is something from the internal discussion about this PR.
I think we should add this field to FeatureFlags
here:
https://github.com/facebook/relay/blob/59c9bc01c1d215b75d6c683f6ee1074a8110fd7b/compiler/crates/common/src/feature_flags.rs
And this PR (or this can be a separate PR) should just add feature_flags
to SingleProjectConfigFile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make the change to move this to feature flags. I didn't originally since it seems like all of the feature flag config was resolved to boolean values, whereas this is a string configuration value, which didn't seem to me like a feature flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a string configuration value, which didn't seem to me like a feature flag.
Fair point.
I general, I think this field
is similar with ConnectionInterface
. I think both of these should be defined on the project_config
here:
relay/compiler/crates/relay-compiler/src/config.rs
Lines 252 to 276 in 59c9bc0
let project_config = ProjectConfig { | |
name: project_name, | |
base: config_file_project.base, | |
enabled: true, | |
schema_extensions: config_file_project.schema_extensions, | |
output: config_file_project.output, | |
extra_artifacts_output: config_file_project.extra_artifacts_output, | |
shard_output: config_file_project.shard_output, | |
shard_strip_regex, | |
schema_location, | |
typegen_config: config_file_project.typegen_config, | |
persist: config_file_project.persist, | |
variable_names_comment: config_file_project.variable_names_comment, | |
extra: config_file_project.extra, | |
test_path_regex, | |
feature_flags: Arc::new( | |
config_file_project | |
.feature_flags | |
.unwrap_or_else(|| config_file_feature_flags.clone()), | |
), | |
filename_for_artifact: None, | |
skip_types_for_artifact: None, | |
rollout: config_file_project.rollout, | |
js_module_format: config_file_project.js_module_format, | |
}; |
Something like schema_configuration
field which is a struct:
struct SchemaConfiguration {
connection_interface: ConnectionInterface,
node_interface_id_field: Option<StringKey>,
}
But this refactoring can be done independently from this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or schema_config
for short, as we already have typegen_config
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alunyov I moved it to a FeatureFlag, just so you can see what that would be like. Let me know which approach you'd like to move forward with!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kesne! I importing this internally.
@@ -130,6 +134,7 @@ fn apply_common_transforms( | |||
program: Arc<Program>, | |||
connection_interface: &ConnectionInterface, | |||
feature_flags: Arc<FeatureFlags>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the benefits of adding node_interface_id_field
to FeatureFlags
is that you already have them in apply_transforms
so it's less changes.
a4b3c79
to
6d2b0d8
Compare
@alunyov has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
So, moving this to And I totally agree with you @kesne that it doesn't seem right to have these settings in the feature_flags. All these suggestions were with the idea that we somehow add this One problem was, we could not use I'm working on updates to I will also add new property on the |
The changes to the |
A quick update. I think there will be another iteration on top of the |
Summary: A follow-up for this PR: #3638 Pass schema configuration to `relay-typegen` and use the `id` name for the config. Reviewed By: kassens Differential Revision: D33479397 fbshipit-source-id: 617d341609c0749ca2e6921b74a6354508f70455
@alunyov There could be pagination bug Related to this pr. If we configure the compiler to use a custom id, I found pagination Let me know if I should have a more sandboxed example and a new issue. |
@Lalitha-Iyer I opened an issue for this already. Sadly I haven't had time to debug and the issue hasn't received much attention. |
@Emilios1995 Appreciate you opening an issue. I will follow along. |
This adds a new option to the Rust compiler,
nodeInterfaceIdField
, which allows customization of theNode
interface'sid
field. I initially tried to determine this via inference, but it's entirely possible that theNode
interface has multipleid
fields, so I figured explicitly specifying it made more sense.