mattpocock / boilersuit Goto Github PK

Having thought about proptypes, the best way for suit to handle them is to put them in and change their names, but allow you to comment them out. That's a tricky implementation.

Create a saga generator if "saga": { }.

This saga generator should not be controlled by // @suit-start and // @suit-end, since it needs to be customisable. It should just plonk a commented-out version of the boilerplate in a function by the correct name does not exist.

{
  "initialState": {
    "something": {
      "keyOne": true,
      "keyTwo": false
    }
  }
}

Currently, suit does not create selectors for sub-keys of objects. For instance, keyOne and keyTwo above. It should.

Future changes to boilersuit may cause bugs in previous suit.json files. That means we need to have some way of restricting which versions of suit can be used for different files.

Ideally, you will keep a version of suit in npm for each project, and not have it globally. This would solve this issue.

Sometimes you need to suit up, forcing everything to update without watching afterwards. suit up --force

In the future, this could support environment variables, such as what type of project this is.

For now, it can just be for whether it warns you about elements without descriptions.

That gives us a way of warning users if things need to be deleted, and means we're never accidentally deleting their code.

Currently, we allow crap inside // @suit-name-only tags to stick around indefinitely, which means a headache for users having to occasionally delete it.

This could also be a tag inside the .suitrc file - deleteInNameOnly: true

Needs to handle the case of no previous imports in a file.

Sometimes, you need to pass an action to a saga and not have it update state. So we need a "payload": true.

Suit requires explanation - a series of readme videos are incoming.

After generating a suit of actions/reducers from a clean boilerplate, the selector attempts to use selectDomain and fromJS without ensuring they are imported first.

Allow for adding comments, which will appear in reducer.js and index.js

This is crucial for when you want to import your own logic into the reducers. Rewriting the whole reducer each time is not good enough for how extensible we want reducers to be.

Create a command which ejects suit from a subdirectory, so it deletes the suit file and removes any // @suit-line, // @suit-start and // @suit-end

These can be added as traditional // @suit-start, // @suit-end pieces, as their proptype never changes.

In fact, no they can't - they still need to be commented out by the user if they have a pre-commit linter.

This is preventing the Prop_Types release from being ready. Should be done next week.

Need to create tests, such as index.test.js, selectors.test.js and actions.test.js.

Currently, there is some console.logging going on in the main functions. Need to abstract those out to somewhere else, to keep the write functions just string replacements.

This is a bit less annoying than the pure warning, and helps you write the thing quicker and with fewer errors.

Boilersuit should not half-arse things - if the environment is not set up for it, it shouldn't half-transform a document.

That means that it should fail early and fast if it can't find the correct syntax structures to hold its data.

We need to know that every module of boilersuit works. So, write some unit tests for it

Currently, there is no way to delete suits - you have to do it manually. Booooo. This could also be part of a suit eject call.

In other words, takes a suit with tens of reducers and turns it into a suits folder with many smaller suit files in it.

This could be overkill on the automation front.

This means we need to change the logic of some of the search functions. Mostly an internal bug, but left here to remind me to work on it.

Imagine that if you wanted to define a new API action, you could define it in a suit folder with getTweets.json.

You would write the API call yourself, passing back a payload that would be given to the onsuccess action.

That means that throughout your app, in the suit.json files, you could just import the ones you wanted in an array:

{
  "import": [
    "getTweets",
    "getFacebookLikes"
  ]
}

This would solve two big issues: duplicate suit.json files, and those endless apiClient.js files you find where the API methods are just listed out. Instead, we should couple them to our suits so it's easier to see how they flow into the state.

I think 'extends': 'single' would also work great. Are there any other quick patterns we want to be able to do in a suit file?

Boilersuit shouldn't be used to trample over previous code - if there is a domain with the same name, or an action of the same name already present, this can cause errors. We should ask the user to delete their previous stuff first.

This issue can be for any readme suggestions.

As of now:

Make clear that the suit.json needs to be in the root of the container folder you want to add reducers/actions etc to.

Remove a suit.json file and all of the suit-managed parts of the files in its container

It would be really cool to be able to specify Flow or Typescript in the suit up command, automagically generating and associating interfaces and types in the appropriate places. Something like suit up --flow.

Currently, we are rather bound to the folder structure of react-boilerplate, and its pattern of segmented containers. How would suit handle a plain redux environment? Where would the suit.json file go?

Boilersuit thrives in regimented folder structures. Once we have an idea of a folder structure for a plain redux project, we can get started extending it.

Currently, boilersuit is quite poor at working with arrays and objects. This comes from an issue in prod where I am considering merging two objects, but realising that suit can't cope with it.

A simple change:

{
  "actionName": {
    "describe": "Merges two objects together, and concats two arrays",
    "merge": {
      "anObject": "payload.otherObject"
    },
    "concat": {
      "anArray": ["anArray", "payload.otherArray"]
    }
  }
}

suit overwrite <folder>

A potentially dangerous command which would entirely overwrite a directory's existing reducers. Useful for when you want to gut out existing code and replace it with suit-managed code.

Currently, when the suitfile updates it has no idea of what has changed. This means it goes in and re-renders everything. On a large, sprawling project, this could be very detrimental on first load.

This proposal would add a folder in each container marked .suit, which would hold a file called suit.old.json. This file would be the previous version of the suit file. This means that when the actual suit file changes, it can be compared with suit.old.json and only the actual things that have changed get updated.

This will give us a huge perf improvement, as well as adding a folder for adding more metadata in the future if necessary.