Skip to content
This repository has been archived by the owner on Oct 4, 2024. It is now read-only.

Metrics events - add utils to support mixpanel integration and persisting user settings in shell. #323

Merged
merged 24 commits into from
Apr 24, 2020

Conversation

janedegtiareva
Copy link
Contributor

@janedegtiareva janedegtiareva commented Apr 21, 2020

utils/eventtracking.js Outdated Show resolved Hide resolved
@mikedotexe
Copy link
Contributor

In standup I heard that we wanted to reach consensus on something? I don't see any details on what is being asked. Looking at the code, this seems great to me. I think adding events to every command is the only way to go. Can't wait to see this live!
Looks like we've got some linting issues, FYI

utils/settings.js Outdated Show resolved Hide resolved
test/testsettings Outdated Show resolved Hide resolved
// Persistent shell settings

const getShellSettings = () => {
const nearPath = path.join(homedir, '.near-config');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be .near or .near-shell or .neardev?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also let's make this a constant? same for settings.js

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be .near or .near-shell or .neardev?

@ilblackdragon I recommended Jane put it here as it fits with the structure I laid out in the NEP.
https://github.com/nearprotocol/NEPs/blob/974887126800be47a58e968fac5b997db7d50f7d/text/0000-near-shell.md#settings-config-and-key-management

─ awesome-near-project  ⟵ NEAR dApp
 ├── .near-config       ⟵ Stores shell-experience settings and connection configuration
 │  ├── connections     ⟵ Contains files used to connect and deploy a contract (except keys)
 │  │  ├── default.js   ⟵ Default configuration is for development
 │  │  └── localnet.js  ⟵ Custom connection added by user for localnet
 │  └── settings.js     ⟵ Stores near-shell settings, how shell behaves when run in this project
 └── .near-credentials  ⟵ Previously "neardev" this directory contains private key inforamtion
    └── default         
       └── alice.json   ⟵ NEAR account "alice" has private key information here

(the same structure also appears in the home directory)
Based on the comment in the shell NEP, I understood that we were not going to put anything in ~/.near as that's reserved for validator data. We can modify the NEP to be .neardev if we want instead of .near-config. Currently neardev isn't a great name and holds private keys, which the NEP calls to change to a more informative directory .near-credentials that folks aren't likely to accidentally revision. Anyway, that's the thought process. Again, we can modify the NEP.

Copy link
Contributor Author

@janedegtiareva janedegtiareva Apr 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved string literals to const. @mikedotexe thanks for the context for dir structure!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need configs inside project directory?
I really think we should not store any credentials inside project directory - because that's the easiest way to lose them. E.g. #198
I also think settings should live in common directory for all projects.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilblackdragon we don't need credentials, but per-project config is necessary. At the very least, it's important for making sure that people have updated deps e.g. shell itself. I agree that creds and global config should be in a common dir for everything.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@potatodepaulo read the NEP and left comments there - near/NEPs#31 (review)
High level, I don't think there is need in local configuration folder, especially one that starts with . as those directories should be gitignored. package.json can contain settings that should be "clonnable".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we limit the discussion to user defined settings here in order to get the PR in for RL1?

utils/eventtracking.js Outdated Show resolved Hide resolved
@janedegtiareva janedegtiareva changed the title Metrics events Metrics events - add utils to support mixpanel integration and persisting user settings in shell. Apr 22, 2020
@mikedotexe
Copy link
Contributor

Merge conflict 🎗️

@behaviary
Copy link
Contributor

@janedegtiareva looks like it's asking CI to opt in and that's why the build is breaking for this PR.

@ilblackdragon
Copy link
Member

@janedegtiareva we for sure need to figure out how to not show this in CI - we will have this problem in all examples.

@janedegtiareva
Copy link
Contributor Author

@janedegtiareva we for sure need to figure out how to not show this in CI - we will have this problem in all examples.

This was temporary not working due to changing some things due to comments. Back to working again.

@janedegtiareva
Copy link
Contributor Author

Merge conflict 🎗️

resolved

@janedegtiareva
Copy link
Contributor Author

@janedegtiareva looks like it's asking CI to opt in and that's why the build is breaking for this PR.

Yeah this was temporarily broken due to commit /addressing comments churn. Back to working now.

EVENT_ID_TX_STATUS_START: 'shell_tx_status_start',
EVENT_ID_TX_STATUS_SUCCESS: 'shell_tx_status_success',
EVENT_ID_LOGIN: 'shell_login',
EVENT_ID_DEPLOY: 'shell_deploy',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's already addressed in the part 2 of this effort which actually does events for all the things. can we let this be to avoid unnecessary churn?

EVENT_ID_TX_STATUS_SUCCESS: 'shell_tx_status_success',
EVENT_ID_LOGIN: 'shell_login',
EVENT_ID_DEPLOY: 'shell_deploy',
EVENT_ID_DEV_DEPLOY: 'shell_dev_deploy',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not used

EVENT_ID_ACCOUNT_KEYS_SUCCESS: 'shell_account_keys_success',
EVENT_ID_TX_STATUS_START: 'shell_tx_status_start',
EVENT_ID_TX_STATUS_SUCCESS: 'shell_tx_status_success',
EVENT_ID_LOGIN: 'shell_login',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not used

@janedegtiareva janedegtiareva merged commit 92fee29 into master Apr 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants