Unexpected behaviour on import with dynamicTyping

Sorry to disturb you again, but I’ve found this:

If you change your example posts.js to:

const ListActions = (props) => {
  const {
    className,
    basePath,
    total,
    resource,
    currentSort,
    filterValues,
    exporter,
  } = props;
  const config = {
    logging: true,
    validateRow: async (row) => {
      if (row.id) {
        // throw new Error("AAAA");
      }
    },
  };
  return (
    <TopToolbar className={className}>
      <CreateButton basePath={basePath} />
      <ExportButton
        disabled={total === 0}
        resource={resource}
        sort={currentSort}
        filter={filterValues}
        exporter={exporter}
      />
      <ImportButton {...props} {...config} parseConfig={{dynamicTyping: true}}/>
    </TopToolbar>
  );
};

i.e. delete postCommitCallback and add this parseConfig, when you import data with conflicting ids, it will not show the dialog but quit directly. Is it an expected behaviour? Thanks.

[peter-jerry-ye]

• The only problem I can see is which ID should be sent to the DataProvider?

It seems to me it is best to send whatever the user give you, i.e. the parse result from csv, so that the user can have full control. That being said, in the definition of Identifier is string | number, so you can send string. Just mark it in the README if you always send a string in case they put identifier as number somewhere in code.

• If id1 = 2 and id2 = '2' these will become equivalent, so should it always pick the ID from the DataProvider?

I do expect the type in the parse result corresponding to the type from the DataProvider, which is both number in your case. If the type is different but the value is the same, I think it could be safe to say it’s just a type issue: there’s hardly anyone uses two types to define a single table column.

[benwinding]

Hey @peter-jerry-ye, I’ve just merged it in.

Have a test and let me know if there’s any issues.

Also, what dataprovider are you using in your project? just curious