docs: adding working with data pages #4970
Conversation
docs/site/Querying-data.md
Outdated
|
|
||
|
|
||
|
|
||
| ## NOT SURE IF THE FOLLOWINGS ARE CORRECT IN LB4 |
There was a problem hiding this comment.
Not sure if the blow is true for LB4.
There was a problem hiding this comment.
Better to not include it if it doesn't work for sure, imo, could open a follow-up issue for them?
| In LoopBack 4, models describe the shape of data, repositories provide behavior | ||
| like CRUD operations, and controllers define routes (this is different from | ||
| LoopBack 3.x where models implement behavior too). LB4 | ||
| [repositories](Repository.md) provide a couple of create, read, update, and |
There was a problem hiding this comment.
do the CRUD operations only available for the CRUDRepository?
There was a problem hiding this comment.
I think for now all LB4 repositories are extended from DefaultCrudRepository, and it provides those CRUD operations mentioned here. If this is true, then I think the answer is yes.
There was a problem hiding this comment.
cuz i'm thinking Repository doesn't need to have CRUD, so that's why we might want to leave it for a broader usage.
agnes512
requested review from
bajtos,
deepakrkris,
emonddr,
hacksparrow,
jannyHou,
nabdelgadir and
raymondfeng
as code owners
|
|
||
| ``` | ||
| /cars?filter[where][odo][lt]=30000 |
There was a problem hiding this comment.
i know it's not part of the LB3 docs either. It might be helpful to "join" the two conditions. e.g. what should be the where clause if the value ranges from 10000 and 30000. It's out of scope of this PR though.
There was a problem hiding this comment.
Good idea, I think Rifa mentioned it before. I think Querying-data.md will be a good place to introduce the function.
docs/site/Where-filter.md
Outdated
|
|
||
| ```ts | ||
| await productRepository.find({where: {size:'large'}}); |
There was a problem hiding this comment.
Just a question.. in the controller, we can create WhereBuilder or FilterBuilder as an argument. Does it work if we provide the JSON? If yes, perhaps we can list both? Again, I'm good to leave it out of scope for this PR and limit to "translating" the LB3 docs to LB4.
There was a problem hiding this comment.
I think it works with JSON. Will have examples in where-filter.md too.
docs/site/Fields-filter.md
Outdated
|
|
||
| {% include code-caption.html content="REST" %} | ||
|
|
||
| {% include warning.html content=" |
There was a problem hiding this comment.
Since you mentioned this above, maybe you don't need to mention it again?
docs/site/Querying-data.md
Outdated
|
|
||
|
|
||
|
|
||
| ## NOT SURE IF THE FOLLOWINGS ARE CORRECT IN LB4 |
There was a problem hiding this comment.
Better to not include it if it doesn't work for sure, imo, could open a follow-up issue for them?
|
|
||
| ## Overview | ||
|
|
||
| A _query_ is a read operation on models that returns a set of data or results. |
There was a problem hiding this comment.
I think the query here means the query we use for the GET request, where these filters can be applied. Do you have any suggestions?
| Note that to include more than one field in REST, use multiple filters. | ||
|
|
||
| You can also use [stringified JSON format](Querying-data.html#using-stringified-json-in-rest-queries) in a REST query. | ||
|
|
There was a problem hiding this comment.
Can we add a URL example of stringified JSON format for fields filter here? It would be very helpful for our readers to see an example right here without having to navigate away to the link where they will actually see an example for the where filter. Let the link be there, though. Small thing, but makes a big difference.
There was a problem hiding this comment.
Thanks for reminding me! I just realized that the url works well with the stringified JSON ( it has a bug with pure url, see #4992). It will be a good workaround for fields!
| ?filter={"where":{"or":[{"id":1},{"id":2},...,{"id":20"},{"id":21}]}} | ||
| ``` | ||
|
|
||
| <!-- DOES NOT WORK IN LB4 |
There was a problem hiding this comment.
Do we need this commented code?
There was a problem hiding this comment.
From what I tested, this doesn't work in LB4, but we might want similar features in LB4. I use the comment as a reminder.
| level. There are three options: | ||
| - 'nullify': Set `undefined` to `null` | ||
| - 'throw': Throw an error if `undefined` is found | ||
| - 'ignore': Remove `undefined`. This is the default behavior if `normalizeUndefinedInQuery` |
There was a problem hiding this comment.
What do you mean by "Remove undefined"? Could be helpful to show examples of the results in the two snippets below
There was a problem hiding this comment.
This part is commented out as I am confused too 😅 so I am leaving them for future.
agnes512
force-pushed
the
data
branch
4 times, most recently
from
1a12e82 to
b74440b
Compare
Closes #2527
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm testpasses on your machinepackages/cliwere updatedexamples/*were updated👉 Check out how to submit a PR 👈