Clear transactions history when changing projects

[filippsen]

Motivation

"when changing projects, we close the Transactions History panel BUT we don’t actually clear the history"

[filippsen]

This looks harmless at first, but I would add extra warning lenses to it, as the request does not play well with the way things work at the moment.

Reasoning This change alone doesn't play well with the idea of state that is kept for preventing recompilation and redeployment. If you simply clean up the transactions history, you will end up with already compiled and deployed projects and no entry in the Transactions History to refer to.

Code Disregarding the most important factor mentioned above, here is what I know about the Transactions History: from my understanding, the way the code is written it always reads all transactions that were ever registered. The transactions data is held by TransactionLogData (src/components/blockexplorer/transactionlogdata.js). There is currently no way to clear it. Something like the following could be added:

clearTransactions=()=> {
    this._transactions=[];
}

Then, the shortest path to accessing it would be adding to onProjectSelectedHandle, the following code:

if (this.props.router && this.props.router.control) {
    const project=this.props.router.control.getActiveProject();
    if(project) {
        project.props.state.txlog.clearTransactions();
    }
}

Again, I don't recommend doing it without reassessing all other related data that is kept around.

[waheed25]

@filippsen i want your suggestion about this is if we store our TransactionLogData in a separate array and displays the data of new generated array which is the clone of TransactionLogData in trans view and clear this new array on switching the project.In this way we will not mutate the original data of TransactionLogData . @filippsen what is your thoughts about this?

[filippsen]

@waheed25 As stated in the text, if you clear transactions history when switching project, you lose visual reference to the already deployed contracts. Mutating data is not the problem in my view, so that is indifferent.

[javier-tarazaga]

@filippsen I actually didn't know that when closing a project we keep all that state lying around. What was the reasoning in the first place to keep all state when changing projects? The only thing is that from the user's point of view they will not know that state is kept around (at least I wouldn't), meanwhile the trans history panel actually will say another thing.

[filippsen]

@javier-tarazaga The reason to keep state, regardless of which projects are selected, has to do with the generated output. Additionally, if I'm not mistaken, that feature was added before the notion of projects was introduced.

What happens is that a set of data is produced when you compile. Another set of data is generated when you deploy. Other than for optimization purposes, which prevents redoing the same actions without the need, the deployed data, in particular, is important for receipts and addresses.

The transaction history panel shows what has happened, in the context of the project and selected network. The data is supposed to be still there afterwards. In fact, when you access an already deployed project you can interact with it without the need of recompiling or redeployment. It becomes more evident when you deal with non-Browser networks.