Discussion with team

[atherdon]

Part 1

Organizational problems

Current version of plugin is ES5 version.

Problems:

• not minifying, so when we deploy on Netlify our create-react-app`s it's crashing deploy.
• We didn't build our code, didn't using ESLint and tests

Pros:

1. it will be minified and don't break build of 6-8 react projects that we have
2. it will move from code-commit to code-test-commit-publish_test approach - which is better because robots will test what we've done
3. each time our code will be compiled, so the code will be better by magic
4. it'll have all es6 features, that we partially use.
5. I'm focused on this transition because I don't like to have the same things in a few places...

Cons:

1. I should explain how to work at it. so it'll require some of my time
2. we have a lot of unfinished stuff, that bothering me - I still don't have "feeling" that we have everything inside at this repo
3. testing approach of ES6 version will require additional time for everyone, involved to development of this project.
4. it'll take a lot of time(can be a few weeks), before we'll be able to publish that es6 version and our developer start to use it
5. we should finish testing part at our fetch plugin, because it's not finished - we're in between with it.

Code organization and structure

My goal was just to keep all static files/data in the same separated place at the beginning.
So we didn't keep a lot of attention about what structure we have.
right now we have 2 main folders: data, projects.
Data just have all of our files/tables/structures at separated folders.

Projects have sub-folders, each subfolder

! i don't like the way how we're debugging our new methods. we have a play.js file where we can console.log some of our functions, but it's not cool to have them into our npm published version.
this can be fixed by moving to ES6 + Babel7 builds, where we extend *play.js files out, but still keeping them at our github repos.

Projects

Problem: Number of project/branches is growing, and we add new methods and everything start to look overcomplicated.

[atherdon]

After the conversation with Vadim we still didn't figure it out but decided to try building big objects, that will contain whole information. aka one object is equal to the whole database. details - #60
i'm working on the next parts of this "chat", will publish it soon

[atherdon]

By Moving out JSON files

• we'll have a better name for the package, that store static food data

• it will more easy to test and compile.

• it will have only one function: keep static files and return data from them
  Example: Some days ago Maria was updating JSON files, and build generate an error. And this is a good situation because we have some tests, that send us alarms. But it can be done in more automatically and intuitive way. Split also make code less confusing.

• it will give us additional perks as promotion and exposure.

• it will help us with the transition of our plugin into a next major release

• it will be less confusing for our ML team, that working right now with OCR script
  https://medium.com/groceristar/ocr-project-part1-simple-introduction-ab7b64bf1864
  https://medium.com/groceristar/ocr-project-part2-details-85739239f42
  https://medium.com/groceristar/ocr-project-part3-links-collection-2cfc58904caf

Before we have another repo, that store an old code, that we move into fetch plugin. npm link, github

---

At the first stage, it was just a separated store of static files.
Then we start to add more methods and then we move everything into our current repository. If we'll go into separation way - I propose that we should move our data to that repository. But we'll need to clean it up and update the JSON files. And then connect that plugin with fetch plugin.

Side notes:

1. I find some cool plugins, like https://www.npmjs.com/package/gray-matter
   it can help us with parsing methods. It has some intersections with another project that I want to build, so maybe we should review it too and decide to use or not right now.

2. I assume that we can create a separated file, that will handle all file imports.
   as we did with at getRawFiles

3. In order to make smooth transition - we adding a new layer for connecting our files upgrade importing files process #177

---

Plan

0. Discuss this option. decide when we'll do it
1. Review/Compare data that we have at static-data repository and fetch. Can we delete everything from static-data and move our files?
2. what minimal impact should we make at static-data? The main goal of this repo will be to return data from files. But should we add babel, builds, tests, etc? It'll be cool to keep it as clean as possible, but I think it's ok to have default JS methods as parser and get and basic tests coverage.
3. discuss what methods we will move to static-data. I need a complete list before we'll start to do it. it'll save us time. we also need to figure out what tests should be moved too. I assume it'll be easy to understand when we'll have a complete list of methods that we're moving - so we'll move all tests, related to that methods...
4. moving data away, running all tests, publish on npm an update. connect it with fetch and run fetch tests in order to understand that everything works as it was before.
5. should we update documentation, readme, docu website?

[atherdon]

hi everyone, need your opinion on this @kraftaa, @vadim9999 @Avuidrauxs

[atherdon]

@sanchit94 this is a task that paint the big picture of upcoming changes

[atherdon]

With the latest changes from Maria(we increased the number of grocery lists from 8 to 28). I think it's crucial to update the way how we merge all the data together. It's easy to illustrate - just open 'data/Ingredients' and you'll see how much files we have there. It looks scary and we should address that.

[Avuidrauxs]

@atherdon , Oh sorry to join this conversation late.

[atherdon]

other problem: it's hard to validate the structure of JSON file when we're working with it manually. So i install a plugin 'jsonlint' and at the root of the package, we have a config file for it. Right now i add only grocery.json, but I assume we'll add all of our files to this file and run validation checks. It works only from CLI or at Travis CI builds. It'll throw an error when something is wrong.

@aanchirinah no prob

[Avuidrauxs]

@atherdon , I absolutely agree that we switch the plugin to ES 6 and strongly follow ESlint rules

[Avuidrauxs]

@atherdon , I can start converting some projects to ES 6 for you including adding tests. Just guide me on how you want it done.

Also regarding the JSON files, I need to research more and reflect on your findings to give a detailed response

[vadim9999]

#198