Thoughts about the IDE architecture #2739
Replies: 5 comments 18 replies
-
|
I think most decisions boil down to a few concepts:
What is really great about this whole discussion is that it's an architecture discussion :) React make it very explicit what you pass a props, so it's a pleasure to discuss: "should we put this prop here or here?" "Is this component responsibility really to do the renaming, or should we put it in a higher component?" Note that I agree some components are requiring too much stuff, like the |
Beta Was this translation helpful? Give feedback.
-
|
Note that all this discussion is hard to do without concrete examples. In the one you've listed:
I'm happy to consider refactoring of some components if they are too dumb/too smart. That's what is great with React: unhappy with a component? Search the whole codebase for its usage, change the props, done! Flow (or TS in the future) will yell if you forgot anything. |
Beta Was this translation helpful? Give feedback.
-
|
Ah I see, I indeed completely missed that the EventsFunctions list was used somewhere else. I think my main issue is actually how much default exports are used, as they prevent many IDE tools from working (auto import autocompletions, searching for useage of the exported function/component...) which is truly what makes those "issues" painful to deal with. Would you think a refactor to convert all default exports to named exports and enabling the eslint rule to warn against using default exports would be a good idea? |
Beta Was this translation helpful? Give feedback.
-
Yes! Happy to consider this if there is a "codemod" (or just manual PR to do this progressively).
I'm fine adapting the codebase to use the named exports as long as the name of the "main" component in a file is also the name of the file. |
Beta Was this translation helpful? Give feedback.
-
|
Hm I had an idea, but I am unsure if it is a good one. What if we used for interacting with the project a sort of decoupled system for handling the data, where we would have operations that the component can call that do all the changes to the project. Like, it could look like this mockup: // ProjectState.js
let project;
export const loadProject = () => {
project = gd.loadTheProject();
}
export const useProjectSettingsState = () => {
const forceUpdate = useForceUpdate();
const state = {
name: project.getName(),
author: project.getAuthor(),
};
const chageState = (setting, newValue) => {
switch (setting) {
case "name":
project.setName(newValue);
break;
case "author":
project.setAuthor(newValue);
}
forceUpdate();
}
return [state, changeState];
}
export const useExtensionFunctionListState = (extensionName, behavior) => {
const forceUpdate = useForceUpdate();
const extension = project.getEventsBasedExtension(extensionName);
const eventsFunctionsContainer = behavior ? extension.getBehavior(behavior) : extension;
const state = eventsFunctionsContainer.getAllNames().toJSArray();
const changeState = (setting, args) => {
switch (setting) {
case "rename":
// Do verification and stuff
eventsFunctionsContainer.set(args.newName, eventsFunctionsContainer.get(args.oldName);
eventsFunctionsContainer.delete(args.oldName);
break;
case "moveUp":
eventsFunctionsContainer.offsetIndex(eventsFunctionsContainer.get(args.functionName), -1);
}
forceUpdate();
}
return [state, changeState];
}// ExtensionFunctionsList.js
import { useExtensionFunctionsListState } from "ProjectState";
export const ExtensionFunctionsList = ({ extensionName, behavior }) => {
const [list, changeState] = useExtensionFunctionsListState(extensionName, behavior);
return list.map(function => (<>
<p>{function}<p>
<button onClick={() => changeState("rename", function, "new name")}>Rename</button>
</>));
};// ProjectSettings.js
import { useProjectSettingsState } from "ProjectState";
export const ProjectSettings = () => {
const [{ name, author }, changeState] = useProjectSettingsState();
return (<>
<TextField value={name} placeholder="Project name" onCommit={(newValue) => changeState("name", newValue)} />
<TextField value={author} placeholder="Author" onCommit={(newValue) => changeState("author", newValue)} />
</>)
};This is just a simplistic mockup, but if done well such a pattern would have multiple advantages i believe:
It also would not require any big refactor, as it could be adopted gradually (nothing stops us from still passing down project and other libGD objects down while having this alternative solution). |
Beta Was this translation helpful? Give feedback.
-
|
I just realized, what I describe here is pretty much redux 🤔 |
Beta Was this translation helpful? Give feedback.
-
Ah! I was about to write exactly this ;) It's not a bad pattern per se but also comes with costs:
The last two points are almost details. What I'm really concerned is that first point ("yet another" layer of abstraction). The project by itself is already structured in "atoms"/"molecules", for example a project contains scenes, that contains objects, that contains effects... so we should for most components be able to pass just what is needed. It's true that project might often be needed. For example
That's a good thing, but React hooks and pure functions should handle this.
I agree this is a nice goal, but I don't think this is making it easier, we'll need to rework in any case the way the project is handled to allow to serialize it (easy, we're already doing this) and update it from a serialized value (kind of ok, but we need to be careful about what we keep in memory) or solve conflicts.
That's a good advantage, but still requires you to create "undo" operation for all operations (how do you undo a scene deletion easily?), unless again you adapt the project handling to allow to easily unserialize a previous value and the UI automatically update. |
Beta Was this translation helpful? Give feedback.
-
The way I see it, that would not be adding a layer but moving one. Currently, the workflow is like that:
The new workflow would be:
Not that much of a difference or increased workload to my eyes, especially since it can spare time and work with the other advantages.
The idea wouldn't be to have one global state, but to have one state ("redux store") per component that uses project. That way, only if data affecting the component has been updated will it update. For example, if a component did something like this currently: const ProjectEditor = (project) => {
const forceUpdate = useForceUpdate();
return (<>
<SemiControlledTextInput value={project.getName()} onCommit={(newName) => {project.setName(newName); forceUpdate();}} />
<SemiControlledTextInput value={project.getAuthor()} onCommit={(newName) => {project.setAuthor(newName); forceUpdate();}} />
</>);
}It would rerender the component ProjectEditor every time a value has finished editing anyways, and doing this won't make it less optimized: const ProjectEditor = (project) => {
const [{ name, author }, changeState] = useProjectSettingsState();
return (<>
<SemiControlledTextInput value={name} onCommit={(newName) => changeState("name", newName)} />
<SemiControlledTextInput value={author} onCommit={(newName) => changeState("author", newName)} />
</>);
}As it would only rerender whenever changeState is called as well.
Basically, what I am suggesting is making components unaware of
This is a pretty good way, as you only get the data you need when requesting some data, rerender what you need etc.
This isn't a reliable or scalable way to do it though. First, it would take a lot of memory, and if we use compression/diff, it would slow everything down. Secondly, it would still have to be added manually in some way everywhere where you want a change to be undoable, for it to serialize the project when that thing is changed. Third, it may not work for many things. For example, you could try to use that with events functions extensions, but lets say I add one, then undo the adding using this method, it would not work as it would only have changed the project to not have the events functions extension anymore, but it wouldn't have unloaded it from the JsPlatform and it would still be there until the IDE is restarted/the JsPlatform is reinitialized. And Fourth, serializing the whole project would mean that an undo operation modifies the whole project, rerendering the MainFrame and thereby the whole tree. That sounds a lot like the nightmare you described when talking about redux, and is something we want to avoid. I think one undo function per operation is not so bad, as it allows to have full control, and therefore have a quick and light undo function. Else, we can also try to make a utility functions that helps to create such undo functions fast, maybe even via serializing like that. Additionally, this would also allow to undo one specific change in the stack, kind of like reverting one older commit on a git tree, and if we define every undo method we can also add a text/icon to each one of them to have a nice visualization of the undo stack like in paint.net: |
Beta Was this translation helpful? Give feedback.
-
|
This is very basic, not 100% satisfied with the way I do the undo but it works and is good enough IMO, and I haven't done the realtime collaboration part yet, but here is a working PoC I just made with a type safe utility function for creating such states with an undo stack: https://github.com/arthuro555/example-react-dispatching |
Beta Was this translation helpful? Give feedback.
-
|
I might have got way too carried ahead but I began making a whole library for this: https://www.npmjs.com/package/create-project-state |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for still being insistent but I can't help but think of this each time I read From the lack of any answer, I infer that my points were unconvincing and not answering your concerns, so I will try to summarize my opinion on the matter again while trying to keep your points in mind.
If it concerns you too much, I think we can try to find a solution. For example, generating all boilerplate code automatically from
I think that overall the benefits in DX (no dealing with force update, having one centralized place for IDE validation instead of being scattered among components, no dealing manually with the undo stack, no dealing with modification in another component...) outweigh the costs (one more abstraction to deal with).
I'm not sure if we are talking about the same thing, I am talking about moving functions like
Most operations probably could be generated automatically, for example when a string, number, boolean, etc has a getter and setter, we can automatically generate code like this (pseudo-api): function setString(variable, newValue) {
const previous = variable.getString();
const undo = () => variable.setString(previous);
const redo = () => variable.setString(newValue);
UndoStack.push(undo, redo);
redo(newValue);
}The generation of this boilerplate could be done from the IDL files, just like how the types are currently generated. For more complex operations, for example, if the returned type is a complex class, we could also autogenerate something based on gd::Serializer. |
Beta Was this translation helpful? Give feedback.
-
|
I was not indeed convinced by everything ;) Sorry for not answering. Here are thoughts when reading your latest points. I think we agree on a few things, though I don't see it clear solutions:
There are also other things I'm less convinced about - potentially because these are independent problems:
Again, these things are interesting problems, but I believe we're conflating them in the same issue while it's separate stuff. Overall I would say that I'm interested and mostly agree with your observations - but I'm not yet confident that what is suggested is an actual solution. I'm afraid we would start implementing this and end up writing a lot of code, without achieving a proper undo/redo, without making live collaboration easier, without improving the re-renders.
I think that's it! :) |
Beta Was this translation helpful? Give feedback.
-
|
So I thought a bit more about this, and indeed I realize now that adding another layer here is not a good idea, and not even necessary for what I want. We can actually do it all in C++. I was proposing two main things. I'll make a post for each to discuss them independently as they are rather different. Here is the first one: For any project mutation, if possible we should implement an undo operation. We could make it easier by having a global undo stack, and we could make macros for simple data structures like strings and numbers, for example (untested pseudocode to illustrate the idea): // UndoStack.cpp
struct Operation {
std::function<void()> do;
std::function<void()> undo;
Operator(std::function<void()> do_, std::function<void()> undo_) {
do = do_;
undo = undo_;
}
}
class UndoStackClass {
private:
std::vector<Operation> past;
std::vector<Operation> future;
public:
do(std::function<void()> do, std::function<void()> undo) {
Operation o(do, undo);
past.push_back(o);
o.do();
}
undo() {
if(past.empty()) return;
Operation& o = past.pop();
future.push_back(o);
o.undo();
}
redo() {
if(future.empty()) return;
Operation& o = future.pop();
past.push_back(o);
o.do();
}
};
UndoStackClass UndoStack;// Project.cpp
#include "UndoStack.cpp"
class Project {
GD_PROPERTY(gd::String, author)
GD_PROPERTY(gd::String, name)
// GD_PROPERTY expands to
private:
gd::String name;
public:
gd::String GetName() { return name; };
void SetName(gd::String name_) {
gd::String oldname = name;
UndoStack.do([this&](){
name = name_;
}, [this&, oldname]() {
name = oldname;
});
};
};We could also make generic "Container" data structures integrating the undo stack: class Map<T> {
private:
std::map<T> map;
public:
T Get(const gd::String& key) {
return map.get(key);
};
void Set(const gd::String& key, T item) {
if(map.has(key)) {
gd::SerializerElement newItem;
item.SerializeTo(newItem);
gd::SerializerElement oldItem;
map.get(key).SerilaizeTo(oldItem);
UndoStack.do([this&, key, newItem](){
map.get(key).UnserializeFrom(newItem);
}, [this&, key, oldItem](){
map.get(key).UnserializeFrom(oldItem);
});
} else {
UndoStack.do([this&, key, item](){
map.set(key, item);
}, [this&, key](){
map.delete(key);
});
}
};
void Delete(gd::String key) {
if(!map,has(key)) return;
T item = map.get(key).Copy();
UndoStack.do([this&, key](){
map.delete(key);
}, [this&, key, item](){
map.set(key, item);
});
}
// etc
};I think that this would require a bit of effort to add such an undo stack to the codebase, but once it is added it would be a minor effort to actually implement an undo function each time we add a new project mutation, and it would really pay off in user-friendliness by allowing to have very fine-grained undo-redo and make sure that anything you do can be undoable and redoable. It is a basic expectation from any user today from an editor to have a fully working undo-redo feature, and to be honest if there is any reason that might make me want to stop using GDevelop, that lack of usability of the undo-redo would be it. |
Beta Was this translation helpful? Give feedback.
-
Yes! That would be great, but the disadvantage of this is that this would add back that new "layer of abstraction" that you urged me to remove, since that would require making a dedicated object for each possible object mutation, that describes the mutation and how to do/undo it. |
Beta Was this translation helpful? Give feedback.
-
|
Though, serializable commands would be way easier to do in javascript, as we can define a "path" for a command's target more easily. For example, if I have a const Schema = {
Project: {
behaviors: ["Behavior", "getBehaviors"],
eventsFunctions: ["EventsFunctions", "getEventsFunctions"],
},
Behavior: {
eventsFunctions: ["EventsFunctions", "getEventsFunctions"]
},
EventsFunction: {},
};
const command = new RenameEventsFunctionCommand({ to: "NewName", path: ["behaviors", "eventsFunctions"] });
command.apply(project);
// .apply() would use the schema to find the EventsFunctions to rename, for example like this:
let current = [Schema.Project, project];
for (const segment of path) {
const [currentSchema, currentObject] = current;
if(!currentSchema.hasOwnProperty(segment)) throw "Invalid path segment '" + segment + "'";
const [subSchemaName, methodName] = currentSchema[segment];
const subObject = currentObject[methodName]();
current = [Schema[subSchemaName], subObject];
}
const [schema, object] = current;
if(schema !== Schema.EventsFunction) throw "The path did not lead to an events function!";
// Now that we have the target actually do the operation
object.rename(this.oldName, this.newName);That does look a bit complex, but I cannot think of a better way of accounting for different targets. If we add a static list of such properties and their getters on each class, we could use the class of an object as a schema, and we could also use that list to autogenerate serialization/deserialization code. |
Beta Was this translation helpful? Give feedback.
-
|
Random idea as I read this: we could have a file similar to Bindings.idl that contains the functions that are callable for all classes in the undo/redo stack (to avoid RCE/ensure there is no huge risk of crash). if I deleted an entire scene, how do I undo this? Where is deleted the scene stored? |
Beta Was this translation helpful? Give feedback.
-
|
If we make all commands serializable, we can add the JSON of the scene to the scene deletion command. Pointers should not be a problem since to be serializable we cannot put a pointer in a command anyways, we have to reference a scene by name, and since the scene deletion operation is after the operations that mutate it, we cannot undo the ones mutating it before restoring the deleted scene. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds fair!
Additional question to continue, assuming we can store the data and the operation to another object starting from the root of the project:
For example, if I change the parameter of an instruction of an event of an external events sheet of a project. At the level of the component handling the parameter, when doing the mutation, we need to push something on the "Undo stack", with the full path. This component should not worry about the full path, it should be handled by the parent. So are somehow the component recursively passing a "partial path to the edited thing"? Like: undoStack would be a class that returns a new instance of itself when you call "add", with the added "path" passed as parameter. All of this up to the top of the stack? Note that this "path" approach is not typesafe. Which might be an argument to bake the undo/redo into the C++ classes, or at least something that does a semi automatic job. |
Beta Was this translation helpful? Give feedback.
-
|
The second thing I am proposing is applying to each "project data structure" (a data structure that ends up being part of the game.json) an observer pattern. Why?An observer pattern has multiple qualities that would improve the editor. The biggest issue it solves is what I call "desynchronization of state", not sure what the actual term is for it. Let's take as an example the following component tree: Both display the object and use forceUpdate when they modify it so that they always show the up-to-date version of the object. The way this is combated currently is by passing a prop that does a forceUpdate from the oldest common parent down to each components using that piece of state, so that all children are rerendered and show the up-to-date piece of state: The problem with this approach is that it is not scaleable:
Examples of desynchronization can be found all over the app right now, for example changing a layer's name doesn't updates the properties panel until we force it to rerender: By making each data structure's instance individually observable, we can fix all of this! Additionally, this further limits rerenders even among multiple instances of components, as they can listen to the specific instance of project state they are using, instead of using a callback generalized to the class of the piece of state. How?The C++ code should be fairly straightforward and a good use case for inheritance, with something like this (note that I am using integers instead of a set of functions references as I am unsure of how functions references are processed by emscripten, but if it does work would be a better way): class Observable {
private:
std::map<size_t, std::function<void()>> listeners;
static size_t id_gen = 0;
protected:
void OnChanged() { for (auto f : listeners) f(); };
public:
size_t Subscribe(std::function<void()> f) {
size_t id = id_gen++;
listeners[id] = f;
return id;
};
void Unsubscribe(size_t id) { listeners.delete(id); };
};We need to be careful to not forget to call For the JavaScript side, we could use a very simple hook: const useProjectState = <T extends gdObservable>(object: T): T => {
const forceUpdate = useForceUpdate();
React.useEffect(() => {
const id = object.subscribe(forceUpdate);
return () => { object.unsubscribe(id); };
}, [object]);
};To fully eliminate all "unnecessary code" from class gd::ErrorsManagerClass: gd::Observer {
std::vector<gd::String> errors;
void LogError(const gd::String& error) {
errors.push_back(error);
OnChange();
};
gd::String PopError() { return errors.pop() };
}
ErrorsManagerClass ErrorsManager;// Somewhere in MainFrame
React.useEffect(() => {
const id = gd.errorsManager.subscribe(() => {
showWarningBox(
i18n._(gd.errorsManager.popError()),
{ delayToNextTick: true }
);
});
return () => { gd.errorsManager.unsubscribe(id); };
}, []);Now the methods in C++ would simply add code like if(newName == "") {
ErrorsManager.LogError(_("The name of X cannot be empty!"));
return;
}And after moving everything to an observable, we can get a nice, more performant, and easy to work with codebase with a way more readable MainFrame :) |
Beta Was this translation helpful? Give feedback.
-
|
Hmm... I looked a bot more into it and there seems to be a big issue: WebIDL Binder doesn't seem to support passing functions as parameters. I used following code: #include <functional>
typedef std::function<void()> VoidFunc;
class GD_CORE_API Arthuro {
public:
Arthuro(){};
~Arthuro(){};
void callme(std::function<void()> fun) { fun(); };
};and following WebIDL: callback VoidFunc = void ();
interface Arthuro {
void Arthuro();
void callme(VoidFunc fun);
};Right off the bat, the WebIDL parser crashes. It is a simple error though, the I also tried changing the code to use C function pointers: using VoidFunc = void (*)();
class GD_CORE_API Arthuro {
public:
Arthuro(){};
~Arthuro(){};
void callme(VoidFunc fun) { fun(); };
};But it had the exact same effect... At this point, with the previous parser issue, and the lack of documentation of the callback keyword, I declare forfeit and assume it is simply not supported by emscripten's WebIDL Binder. I think what we'd have to do would be to either contribute to WebIDL Binder, which looks kind of messy and hard to understand, or make an inheritable class that we use as a callback, kind of like |
Beta Was this translation helpful? Give feedback.
-
|
I've read that a few times, overall what I think is:
Side note: note that the risk with "observable" stuff is that it pushes away complexity into a cloud of observable states, which can be hard to track. I know that you despise MainFrame large content, but the complexity of the component itself is not that high: it's a matter of passing a bunch of props around, storing a bit of state. By reading MainFrame, you can get an idea of what the whole editor is handling and this is a good thing. The problem of some components being out of sync is slightly independent :) |
Beta Was this translation helpful? Give feedback.
-
If your point is that this is the "React way"/"correct way" to do things, I'd disagree here. React is before anything reactive. To quote the first paragraph of the homepage,
A component should only ever rerender when the data of that component changes. Rerendering a parent when the state of a child component has changed to keep other children components in sync is against react's principle of a component reacting to a modification of it's own state. Props are made to make components flexible, not to drill down a forceUpdate (not to mention that forceUpdate is most definitely not "canonical react") instead of letting components be aware of their data dependencies and rerendering when those have been updated.
Ok so now i am a bit confused. I brought this up in part because you were the one who told me the other day we do not want to complexify MainFrame, but now you're telling me it is good that it is complex and we shouldn't try to decomplexify it? My point wasn't much about MainFrame getting hard to read anyways, but about the fact that it's the root of the app. By prop drilling forceUpdates from there everywhere we are actively encouraging rerendering the whole app for tasks that do not really need to. To take again your prior example of a rogue component, we are giving them the power to rerender the whole app. And i think it is much more likely for someone to write accidentally and commit But user experience appart (I consider only rerendering components that need to be UX as this will impact the apps performance), I am indeed not a fan of MainFrame doing way too many things. For example, let's say i want to change the verification code of scenes names. First thing I'd do is go to the C++ class. Then, since there is no verification code there but obviously there is some at some point since the IDE doesn't allow certain names, I'd check in the IDE. Since i use GDevelop, I know that the place where you rename scenes is the project manager, so I'd go there. No verification code there either, but it uses a prop to do the renaming! Luckily I know that the project manager is only used by mainframe, so i can just go there. And finally there it is! Having one big component doing many diverse operations may be arguably good to have a broad overview of many things the IDE does, but I think that's missing the point. There shouldn't be any of this code in there, because of one of the core concepts of react, components and clean code: separation of concerns & single responsibility principle. It is the responsibility of the data structure to verify that a mutation is valid, and it is up to the UI that requests the mutation to notify the user if a mutation is not possible. It shouldn't be one of a thousands of functions/concerns of some "brain component".
Well, as one of the goals of using the observer pattern is making components not rely on drilled props from MainFrame for mutating objects they should be responsible for mutating, I'd say it at least is somewhat linked. |
Beta Was this translation helpful? Give feedback.
-
Every time I am working on the IDE, I get very frustrated by a few things. I thought I would share them here because I feel like if those issues were adressed everyone could be more productive, or I could improve my workflow if there is something I am missing.
Lack of global context
The most common example of this is the
gd::Projectinstance, it is often needed pretty much everywhere in the IDE, but needs to be passed down the props, which can be very frustrating when working on a component that usesprojectwith components that do not have it passed down as prop. It requires looking for every usage of the component, then looking for every time those components are used to passprojectdown, etc which is very time consuming, especially when the IDE cannot scan for other components using the current component if the current component isn't a named export.A solution to that problem would be to make
projectglobal state, using for example the context API. I think I have seen this proposition at least once before, so I am wondering why it has been rejected."Overusage" of props.
I consider overusage of props is the splitting of logic of 1 action between 2 components for no apparent reason. Of course, maybe I am just overseeing the reason, but from my point of view, this is wasting much time. Here is an example. Let's say I want to look into renaming an EventsFunction. I may find this first:
GDevelop/newIDE/app/src/EventsFunctionsList/index.js
Lines 126 to 146 in 127a881
But, as you may see, the complete renaming function is not present here, part of it is handled by a prop
onRenameEventsFunction. So now I need to search for all components using it, only to find out that there is only one other component using it, and pass the following prop:GDevelop/newIDE/app/src/EventsFunctionsExtensionEditor/index.js
Lines 233 to 266 in 127a881
I see no reason why this had to be passed as a prop, as EventsFunctionsList can do each operation done in that function passed as :
projectand the events based extension passed down as props and can therefore callgd.WholeProjectRefactorer.renameEventsFunctiongd.Project.validateNameandisExtensionLifecycleEventsFunctionas they do not require any special objects as parametersSo this splitting is only making the code more complex harder to read and modify, without any apparent positive impact.
"Overmodularizing" of some components
The other day, I was taking a look at events functions autocompletions and something that struck me was the following code:
https://github.com/4ian/GDevelop/blob/master/newIDE/app/src/EventsSheet/ParameterFields/GenericExpressionField/index.js#L513-L534
More specifically those props:
https://github.com/4ian/GDevelop/blob/master/newIDE/app/src/EventsSheet/ParameterFields/GenericExpressionField/index.js#L516-L524
I find this annoying because it requires that whoever uses that component separately imports
ExpressionAutocompletionsHandler, and to call the methods manually when passing the props where the component could do it itself. It would be way more straightforward to just passautocompletions={this.state.autocompletions}as props, which contains all the needed data, and let the component call the functions to adapt the list for rendering it via itself itself.One could argue "this is only a view, a Displayer, and it should not do the logic". I would not agree, as this logic is necessary for the component as it expects a trimmed list to function.
This is in my opinion again just making everything more complex when trying to work with that code, because I cannot see when looking just at the Displayer how the autocompletions are trimmed, but need to go look up in the components using it, even though they are trimmed exclusively for display inside it, and if I ever want to reuse that component I have to enter more props
instead of just giving it what I want it to display at once, and have to go import some other functions and call them myself etc. This is just a waste of time as far as I can tell.
Last words
Sorry for what turned out to be this big rant, again I may just be misunderstanding the workflow or structuring logic behind those choices, but the frustration about those points have been building up this last few months and I think that if I have issues with this workflow that other might have trouble understanding it too, and that it may really allow a better productivity and contributors count if the codebase is nice for everyone to work with.
Beta Was this translation helpful? Give feedback.
All reactions