Simulator for Fission Reactors

Lol, a lot changed, @Erik3003 is now in charge of all the Nuclear Reactor stuff, and he seemingly improved a lot of its mechanics. Much work for you to do. :wink:

1 Like

My brain is splitting in two. History is repeating itself. Why, oh why did I ever want to learn a JS framework again? My brain cells want to abandon ship. Please, talk them out of it.

So, I chose React for the web version back when I started working on it (very slowly). However, React has some characteristics that make me curl up and cry in a fetal position, and I donā€™t know the right way to deal with this. Perhaps React (and its uni-directional data binding) is just not the right tool for the job.

Iā€™m making a single-page application, which includes many knobs and switches, toolbars, etc. Because of the nature of React (and the application), the state AND PART OF THE BEHAVIOUR IMPLEMENTATION of these UI elements has to be ripped out of individual widgets and lifted up all the way to the top of the hierarchy. So, if I want to only read or reset some child component state, I have to lift it, and everything that uses it, up to the parent. Now, whether this is okay or not is not yet clear for every case in my app. Iā€™m not trying to say that unidirectional data binding is senseless. However, the way things are looking, by the time this is finished, one might but fart, and the whole app will be (virtually) rerendered for nothing and it is killing me. It is so unneccessary. I also feel like I cannot achieve the level of separation of concerns that I would like when I keep having to leak implementation details of child widgets to the parents. Of course, the correct reasoning would be that it is a concern of the parent if it needs access to some of the childā€™s state, and it is correct to lift everything up. But I think things would be cleaner with some two-way data flow.

What is really bothering me currently is the undo/redo implementation. History should probably be state of the top-level component (I think keeping it outside of a componenā€™t state might have synchronisation issues; not sure tbh). So, when I click something that changes a childā€™s state, it will be rerendered, and the event will be logged in history, causing a rerender of the entire app, when nothing has actually changed. And letā€™s be fair, the initial click will probably rerender everything as well because the state will likely have been lifted up to the top-level component. The overhead keeps piling up. Not to mention that React likes to call everything twice on its own anyway.

EDIT: Reactā€™s documentation is shit. flies away

===== END OF RANT =======================

Fac-torio (wonā€™t let me write as one word because it turns into a link and I may not post links?) is looking like a good option right now. :slight_smile:

BUT THEN AGAIN, I DONā€™T WANT TO PLAY GAMES THAT ARE FUN BECAUSE THAT IS A SPIRAL OF DEATH.

I need some climbing holds to grab on to. OH WAIT, Iā€™M SICK AND MY FINGER IS HURT AS WELL. AAAAAAAAAAA.

===== END OF CRY FOR ATTENTION ==========

3 Likes

Can you try the Link thing again? I think I may have fixed it. ^^

3 Likes

Factorio! Sounds like a spell from Harry Potter.

3 Likes

Okay so what happened is, I added this Word to Link thing (which is an official feature of the forum software), but i did not add the Domains to the ā€œpotential Spam can post links to here without tripping safetyā€ List.

3 Likes

I prefer the Elm pattern myself, which is a reactive single storage pattern

They shouldnā€™t, you should just need to send messages upwards?

1 Like