Skip to content
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

Mixed data and meta #9

Open
apsavin opened this issue Mar 9, 2017 · 11 comments
Open

Mixed data and meta #9

apsavin opened this issue Mar 9, 2017 · 11 comments

Comments

@apsavin
Copy link
Contributor

apsavin commented Mar 9, 2017

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?

@yury-dymov
Copy link
Owner

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.

@apsavin
Copy link
Contributor Author

apsavin commented Mar 13, 2017

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?

@yury-dymov
Copy link
Owner

Sounds good to me.

@lvauvillier
Copy link
Contributor

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.

@yury-dymov
Copy link
Owner

@lvauvillier, @apsavin

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

@apsavin
Copy link
Contributor Author

apsavin commented Mar 15, 2017

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?

@nathan-charrois
Copy link

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

@yury-dymov
Copy link
Owner

yury-dymov commented Mar 15, 2018

@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

@kud
Copy link
Contributor

kud commented Jul 2, 2019

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.

@yury-dymov
Copy link
Owner

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

@kud
Copy link
Contributor

kud commented Jul 2, 2019

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants