• JSON Table Editor
  • About the App
  • Technical Decisions
    • Conceptual Description
    • Component Tree Explained
    • React Table
    • Redux
    • Code Repetition and Wet Code
    • Styled-components
    • Test-Driven Development
  • Roadmap
    • Phase 1: Backend and Testing
    • Phase 2: Typing
    • Phase 2.5: More features
    • Phase 3: Doctor Refactor and the Rewriting of Madness
• Some extra lessons

Se quiser ver a versão em português, clique aqui.

To visit the site, click >>> here <<<

JSON Table Editor

About the App

The purpose of this app was to facilitate the creating of mock data for other projects.
I wanted a way to quickly and easily mock a json list of objects, with a few values randomized here and there, and just plug it in the project being done.

Turns out, now we have ChatGPT, which renders this project largely outdated. But since I was done with a big part of project, I decided to finish it before moving on to other projects.

Technical Decisions

Conceptual Description

First, some conceptual definitions:

• Instance: Some javascript object.
• Property: A field belonging to an instance.
• Table: Both a mental model composed by two data structures, schema and instances, and the file that contain the data from them.
• Schema: Describes the name and type of each possible property found in the instances. Types can be primitives, like strings, date and numbers; composed data, like arrays and objects; or even custom, like user-made widgets.
• Instances: An array of objects that populate the table based on the properties each instance possesses. Not all instances have all schema properties, but the schema properties describe all possible properties of an instance.

And about @ notes:

• @todo: A feature to be added or some general task to be done.
• @dryup: This means I believe that the code could be simplified\abstracted, but I dare not to yet. (The reason for this postponement can be found under the Code Repetition and Wet Code section.) (Also, grug said so.)

@todo update leiame

Component Tree Explained

The App.js is the main component, composed of a shell (MenuBar.js and StyledFooter.js) and the table (JsonTable.js).

The MenuBar.js is reponsible for showing all actions the user can perform.

The JsonTable.js contains the components TableHead.js, responsible for managing properties, and TableBody.js, responsible for managing the instances. Besides that, JsonTable.js possesses buttons for adding new instances and properties, as well as a button for transposing (rotating) the table.

At the root html file, besides the #root div (common to most create-react-app projects), there is a #modal-portal div. I use that together with ReactDOM.createPortal method to render all the modals. Some of the modals are:

• ExpandedCell: It magnifies the cell, making larger texts more readable.
• JSONPreview: It shows how the json file, which contains only instances, will look like.
• MassInsert: Allows mass insertion of values to a property.

React Table

Yes, I know it exists now. I wish I've known before. Major rewrite someday?

Redux

The usage of redux was initially was to create a more complex use of the useState hook. I wanted a list of functions that worked on the same state, with each change triggering a re-render. Passing all setters of state to the components was workful. useContext was considered, but I ended up with redux.

Picking redux was an error, but an instructive one. I've learned to use a very popular tool, that should help my career in a forseable future. However, if I were to rewrite the project, from scratch, I would use jotai and create all atoms necessary.

And, because I've already picked redux, I kept using it for other shared state in the application.

Honorable mention: If reduxjs-toolkit didn't exist, I probably would've abandoned redux.

Code Repetition and Wet Code

There is a lot of repetition in my code. It was on purpose. Before I start to abstract anything I say in front of me, I decided to leave the code being more maleable, as I got to know and understood the project better.

I made the code dryer (DRY — don't repeat yourself) as I felt more confident about what I was doing,

I took this way of doing things from a guy much smarter than I.

Styled-components

This library was chosen as the css solution because I had found out about it as a few week before starting this project. I do have concerns about package size, but these concerns are simply a result of my inexperience about handling performance (reads: I am a noob and have no idea what I'm talking about). I do like the power styled-components gives me, though.

I did adopt a pattern for style organization in the later stages development: component keyring. These work by putting all subcomponents under the namespace of a reusable component. Something like this:

import styled from 'styled-components';

const Modal = {
  Container: styled.div``
  Title: styled.h1``,
  Button: styled.button``
}

The consumption is rather straightforward — simply do a <Modal.Container> to access the container. To use other components, use other keys.

The benefits? Other than an easier time importing elements, using a system that resembles BEM and making me feel clever for a silly reason, there isn't any clear benefits. But I did like this approach, so I plan to stick with it when using styled-components in future projects.

Edit: I will probably not do this anymore. Another person much smarter than me cautioned me about "cute, unnecessary things." But maybe it is a good idea? We will see.

Test-Driven Development

I didn't do it. "It's a small project", I thought. I was wrong. Things get out of hand fast.

TDD and @ notes are both important things in order to keep the code managable for me.

Roadmap

While part of me wants to drop this project ("it's a silly idea!" I repeat to myself), I can still see me using this in the future. AND I want to give my best and see how far I can go when perfecting a project. So, on with the madness!

Here is the roadmap: (items in each phase are not ordered by priority)

Phase 1: Backend and Testing

• Create simple auth system — just something to warm my muscles
• Create a storage for tables:
  • Limit of tables per user (maybe 10?)
  • Limit of table size (8mb, probably, because of localstorage)
• Create signin, signup and landing pages
• Create tests
• Autosave on localstorage
• Undo\Redo

Phase 2: Typing

• New Table wizard
• Schema wizard
• Add DataCell Types:
  • Strings
  • Numbers
  • Dates
  • Booleans
  • Selects\Dropdowns
  • Arrays
  • Checkboxes
  • Radiosets
  • Colors

Phase 2.5: More features

• Mass insert randomly
• Clear all cells of instance\property
• Reverse order of instances
• Make context menu render upwards too
• Add custom scrollbars
• Cells can be highlighted and have their own context menu
• Create composite property groups by combining two or more types (limit of some kind?)
• Add new export types:
  • Decently rendered table as pdf
  • Html table (with styling?)
  • Mongoose populatedb script
• Import json from copy-pasting it into a textbox
• User-custom widgets (?)

Phase 3: Doctor Refactor and the Rewriting of Madness

• Change all state-operating functions to be pure (no mutations, returns new obj)
• Rewrite the whole thing with Typescript and React-Table
• Allow for instance naming (swap from array to object as storage mechanism)
• Use some Tailwind UI framework to redo the styling, removing styled-components. (Maybe adding SASS+BEM?)

Some extra lessons

• Redux state management, React rendering and why the website had jitters: Every time a component's state updates, the component and its children all rerender. Because I have state centralized, the whole page rerenders when add something like a tooltip, or add elements dynamically.
  • I shouldn't be adding elements like this, but I can't simply access elements in the actual dom and append children. Use state is the best answer I have — currently.