json-api-normalizer icon indicating copy to clipboard operation
json-api-normalizer copied to clipboard

Mixed data and meta

Open apsavin opened this issue 8 years ago • 11 comments

It seems that json-api-normalizer can't work if I have an entity with type meta. Am I right?

Why not use entities and result top-level keys, like original normalizr does?

apsavin avatar Mar 09 '17 07:03 apsavin

Hi @apsavin,

Yes, you are correct. I would say it was designed in this way because of "historical reasons". In the beginning, there was no meta. Now it is obvious that from design perspective, it would be better to separate data and metadata entities, and I would probably do that breaking change by the time we reach stable v1.0.

As for now, I would leave it as it is before I don't accumulate more breaking changes.

yury-dymov avatar Mar 09 '17 18:03 yury-dymov

I think, it's possible to fix this behavior without a breaking change using an extra option.

normalize(json, { buildResult: true }) // { entities: {}, result: {} }

We can even log a warning message that normalize(json) and normalize(json, { endpoint }) are deprecated ways of usage of the library.

I can send a PR.

Thoughts?

apsavin avatar Mar 13 '17 08:03 apsavin

Sounds good to me.

yury-dymov avatar Mar 13 '17 15:03 yury-dymov

What do you think about to split it in two independent functions (eg: normalizeEntities and normalizeResults)? So the library is more modular and don't impose the root keys entities and results.

lvauvillier avatar Mar 14 '17 19:03 lvauvillier

@lvauvillier, @apsavin

Maybe we could leave normalize as it is and do as @lvauvillier suggests?

yury-dymov avatar Mar 14 '17 20:03 yury-dymov

Well, sounds ok to me, but usually programmer wants just put result of a request in and get normalized data out. Why do two calls instead of one?

apsavin avatar Mar 15 '17 07:03 apsavin

Was anyone here successful in parsing meta data with a different package? Had been happily using this package but unfortunately we require meta data now. Going through the client-side packages, any recommendations would be great!

Thanks

nathan-charrois avatar Mar 15 '18 00:03 nathan-charrois

@NathanCH Meta should be also available. Please create a separate issue and provide your BE response and what you are getting after normalize call. Or you may read the source code of this package, which is ~100 LOC long, and look at how we are dealing with meta

yury-dymov avatar Mar 15 '18 16:03 yury-dymov

I'm not totally sure of my work yet, but as I previously used normalizr and now this project as we've got now a json:api server, I did a lil trick which is:

import nativeNormalize from "json-api-normalizer" // https://github.com/yury-dymov/json-api-normalizer

const normalize = (json, opts = {}) => {
  const entities = nativeNormalize(json, opts)
  const result = json.data.map(({ id }) => id)
  const meta = json.meta

  return { entities, result, meta }
}

export default normalize

Not perfect but works in my case for the moment.

kud avatar Jul 02 '19 15:07 kud

@kud this looks great :) Might be helpful for some other folks

yury-dymov avatar Jul 02 '19 15:07 yury-dymov

@kud this looks great :) Might be helpful for some other folks

Thanks. We're moving from HAL to JSON:API. It sounds to be more flexible and easier for me as frontend dev to ask the data. Plus I don't need to create any schema, it's already done by json:api convention/son-api-normalizer. Loving it!

kud avatar Jul 02 '19 15:07 kud