testing pt2

[atherdon]

we have different layout types.
and this layout types expect a different data structures inside of them. so if layout expect to have an id - we should pass it. if no - then we should alarm about it

[souzasmatheus]

I am not so sure what this task is about. I am sorry.
I can see that each layout has a different type ('PDF1', 'PDF2', etc), but what do you mean it expects so have an id?

[atherdon]

ok, i think i should give you some details here.
Right now, all these components and their wrappers looks not very logical. Before it was a huge project, where we keep everything.

At the first stage, we have only one(first) component, that works fine.
Then we decide to add 2 more layouts, in order to test and give more power to our users.
First 3 components/layouts related to displaying grocery lists data. I cannot show to you the exact showcase project, because we tear it apart and i think its broken at this moment.

Then I decided to test how we'll print a recipe, not a grocery list. So 4th component related to recipes data.

And when we move all print functionality away - i think it looks reasonable to upgrade the logic of our components and instead of few, make one with different layouts. And this task is part of my plan to slowly introduce you into the logic of how it works.

---

This part is actually related to answering your question:
the main problem will be, when we merge all components together, is that we don't cover well that there a different data structures.

Actually, I added a file: selector.js where we connecting to another our package, that return static data(our groceristar-fetch plugin is like a server replacer, so you can get data without connecting to a real server).
And at this file we have a methods, that return different type of data.
Not sure if you will be able to print that data yourself right now, but let simplify it.

Grocery list usually have this structure(here we have 2 grocery list objects):

And inside of our RenderList component(s) we displaying that data.
But what if i'll push data with another structure? for example i'll delete few fields inside the object? it will cause us trouble. Because this component are not ready for changes in data-structure.
So we need to have test coverage, related to checking what type of data, we passing inside of it.
If you need some samples - I can share with you.

And if something is not clear - tell me - i have a lot of details to share

[atherdon]

an actual example you can see here: https://github.com/GroceriStar/groceristar-fetch/blob/master/projects/GroceriStar/groceristar.test.js#L12
actually maybe we just need to use test from fetch plugin, just adapted to current needs of this component...

[atherdon]

btw, did you accept invitation to our team at github? cannot add you to this repo...

[atherdon]

please follow this link: https://github.com/GroceriStar/pdf-export-component/invitations

[souzasmatheus]

Arthur, I feel like I should let you know why I have not showed up in a while. I got an Udemy course on enzyme and Jest, so I am taking it as fast as I can. As soon as I finish it, I will dedicate to the last task you assigned me to. Is that alright? Matheus Souza Em 16 de fev de 2019, à(s) 23:57, Arthur Tkachenko <notifications@github.com<mailto:notifications@github.com>> escreveu: ok, i think i should give you some details here. Right now, all these components and their wrappers looks not very logical. Before it was a huge project, where we keep everything. At the first stage, we have only one(first) component, that works fine. Then we decide to add 2 more layouts, in order to test and give more power to our users. First 3 components/layouts related to displaying grocery lists data. I cannot show to you the exact showcase project, because we tear it apart and i think its broken at this moment. Then I decided to test how we'll print a recipe, not a grocery list. So 4th component related to recipes data. And when we move all print functionality away - i think it looks reasonable to upgrade the logic of our components and instead of few, make one with different layouts. And this task is part of my plan to slowly introduce you into the logic of how it works.

…

________________________________ This part is actually related to answering your question: the main problem will be, when we merge all components together, is that we don't cover well that there a different data structures. Actually, I added a file: selector.js where we connecting to another our package, that return static data(our groceristar-fetch plugin is like a server replacer, so you can get data without connecting to a real server). And at this file we have a methods, that return different type of data. Not sure if you will be able to print that data yourself right now, but let simplify it. Grocery list usually have this structure: [xx]<https://raw.githubusercontent.com/GroceriStar/creative/master/fetch-examples/grocery-list-structure.png> And inside of our RenderList component(s) we displaying that data. But what if i'll push data with another structure? for example i'll delete few fields inside the object? it will cause us trouble. Because this component are not ready for changes in data-structure. So we need to have test coverage, related to checking what type of data, we passing inside of it. If you need some samples - I can share with you. And if something is not clear - tell me - i have a lot of details to share — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#41 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AkOUD3NGnP8M6HVbAzy-ZGvHPGznIkQTks5vOLckgaJpZM4aSVk1>.

[atherdon]

thank you for letting me know! ok - will wait for you - feel free and come back when you'l be ready