I have noticed newer generations of developers believe they need heavy frameworks like React to develop web applications. Most apps don't need such heavy frameworks. Here's a 500-line "framework" (if you can call it that) https://github.com/Rajeev-K/mvc-router and here's an example app built using it: https://github.com/Rajeev-K/eureka For templates I used https://github.com/wisercoder/uibuilder which is a 200-line lib. This is about as "close to the metal" as you can get, and still be productive.
This hasn't been my experience. 10 to 15 minutes of looking at React Router's documentation was enough to get started with it. The major version bumps, however, have been a little taxing. If it takes six major releases to get the paradigm right, you should've done more research before moving onto the implementation phase.
A while back I was faced with using whatever god-awful backwards-incompatible version of react-router to use, or instead to go for a routing solution that wasn't as insane. I don't remember what I picked, but I think it was page.js. Something that's been around forever. It was astounding to me how much it simplified the whole project. I truly can't figure out what react-router actually brings to the table, considering it's version history, compared to the myriad of alternatives.
I don’t think there is anything wrong with building your own ‘framework’. I feel like there is a lot of good experience gained, and learning to be had from taking this approach. Especially for less experienced devs.
It forces you to brush up on fundamentals, fill knowledge gaps, and practice/ learn design patterns. Also the end result is there is no ‘magic’, you know everything that is happening because you implemented it yourself.
Frameworks are great, but I don’t like reaching for them when I start new toy projects, I want to use it as an opportunity to improve my core JS skills.
I agree. I'm stubborn to take on frameworks as I have a vision and want to code it now; rather than learn and understand the framework to do what I want to create which by then my idea has deflated.
The company I am currently contracting for use Ansible. I've never used it prior and I get where the hype is but to me the whole system is just a mess. Asking the younger developers on "why isn't this working" feels quite embarrassing.
Five different folders, within more folders and then more folders on that; then you've got YAML which if you have one wrong space spews errors. I'm not dissing any of it as when it works when it works they do have their reasons for existence but it just feels so convoluted to do something you could write simply in bash.
Maybe I'm just a cynical SysAdmin throwing "get off my lawn" while wanting to see the world burn. But the era where I am from, where the internet was truly developmental; where if you wanted a CMS you built it from scratch. If you wanted a forum, you built it from scratch is kind of almost deleted from internet history.
Wordpress came a long and it ended all that, though I suppose it had to happen if you wanted more features from the users on the internet. It was a niche in the early 00's to have your own website but now my 70 year-old mother administrates her own website.
No disrespect, but I think you proved @vbezhenar's point. The right way to structure the code is with a framework of some kind, even if it's homegrown.
If there is anything I am trying to prove it is that you don't need complicated frameworks like Angular or React. Those frameworks have gotten too complex for what they do.
I needed the ability to safely execute formulas in my .NET app. My solution was to write a parser and interpreter. Here it is:
https://github.com/Rajeev-K/formula-parser
You can do this already with DataTables, which is basically an in-memory Excel spreadsheet. Bonus is that it also supports Excel functions, and it’s completely safe/sandboxed code.
Routers can be (and should be, IMO) written to be independent of UI component libraries such as React and webcomponents. See an example here: https://github.com/Rajeev-K/mvc-router You can use it with React---and in some ways it works better than react-router.
Yeah I'm not a fan at all of react-router because it's too dependent on React. For redirecting, for example, they recommend you render a <Redirect> component. Which is just bananas to me.
It's not really bananas when you actually start to think of everything 'as components', and consider that 'render' can neatly, declaratively describe behaviour, not just the DOM.
That _is_ how I think about components, but it's still bananas. Render does not neatly describe this behavior because it necessitates setting unnecessary state. That's gross.
Usually when I need to trigger a redirect, I'm in some business-level function. So to redirect this way, I would need to set some state in my store, re-render, then hit the conditional, which would redirect, probably unset that state, and then probably trigger some additional business logic.
When really all I want to do is in the business function, directly trigger the redirect and maybe some other logic without any indirection. redux-react-router exists, but it's API is still obtuse compared to something like redux-first-router.
Then you can use `useHistory` (or `withRouter` if you're not hooks-ready).
I somewhat agree that the <Redirect /> component is not actually that useful, it's only useful in very simple cases like "based on one route plus conditional redirect to another", e.g.:
Since you are talking about using Redux, you most definitely can dispatch push actions with libs like connected-react-router or just use the history API directly (for things like replacing state instead of pushing). Most of the redirects I write are inside business logic and I don't like mixing <Redirect /> in there, too.
Now that hooks exist, this should definitely be the case. Before, HoCs / components with render prop functions were actually useful for doing some additional not-directly-render related work.
You can now use hooks for some things you might previously want a component for, e.g. useFetch instead of <Fetch />, but don't agree "this should definitely be the case". Dogma is never good.
The alternative would be to write a side effect inside your `render()` function, which is illegal -- it breaks the new Concurrent mode rendering, which can call render() speculatively.
I mean, I see why it's intuitively unappealing to you, but there are perfectly good reasons for the design.
There are "perfectly good reasons" in the sense that if you artificially limit yourself to using the React component tree to manage routes, yes it makes sense how they arrived at this solution. But after dealing with it for a while, it's just so obviously not the correct approach, and it's crazy to me that it's the defacto router. Cargo culting at its finest. The router could exist outside of or at a higher level than the component tree.
It's the defacto router because it has gone through many iterations, has lots of users, is easy to bring into a React app, and doesn't fight w/ React, it works with it. Plus there are a variety of approaches to declaring routes. [0]
I'm not sure I see how obvious it is that a <Redirect/> is wrong. But that's fine, I take your point that it's not particularly intuitive.
I'm of the opinion that routing, in general, is a function of application state - and I like to manage my application state with Redux - so I will often also mix in connected-react-router [1]. This lets you do navigation w/ an imperative API [2].
The alternative would be to write a side effect inside your `render()` function, which is illegal
That's one alternative. Another is not to try implementing behaviour that has nothing to do with rendering using a rendering library in the first place.
A horrible amount of accidental complexity has been created in the React ecosystem when people have tried to use it like a full framework. If all you have is a hammer, maybe it's time to consider using other tools as well.
It’s bananas to you that a library with the word react in the name would be dependent on react? It’s an add on you would literally never use unless you are building a react app
My favorite routers to use with React at the moment are redux-first-router (define a route map, and an object in your Redux store gets automatically two-way synced with browser location state; your 'routing' is actually just a switch statement over the current location state), and Next.js (make some component files under pages/ and they get automatically rendered as routes; wrap a filename in brackets and it's used as a query param value wildcard). Both have advantages and disadvantages but are very low-mental-overhead in practice.
HTML custom elements (basis for web components) are intended for things that should be added to DOM. Using it for any other purpose is probably a misuse.
In my personal case I'm using it so the DOM is more literal as to what's happening on the page. I'm of the naive opinion that you should be able to read the DOM and have a general sense of what the site looks like. Since I'm making a single-page site that loads everything at once, I have a webcomponent based router that declaratively states what route will be active given the URL. For example:
not sure what happened, but your code example is almost all tofu (unicode [X]) to me. looks like it's using characters like "mathematical monospace lowercase letter 'm'" etc
edit: unidecoded:
my-router
my-route(pattern="/home")
// some home page
my-route(pattern="/news")
// some news page
Docker is a better way to distribute apps than Electron, in my opinion. From a developer point of view you just build a regular web app, so better than Electron. From the user's point of view, Docker is better because of isolation, and because there is nothing to install. You run just one command to download and run the image. If you want the app to have its own window then use Chrome's "Create shortcut" command. This is indistinguishable from an Electron app, but better. See an app written in this fashion here: https://hub.docker.com/r/eurekasearch/eurekasearch
"From the user's point of view, Docker is better [...] run just one command"
Nope. Your "better" solution just became fundamentally impossible for 99.9% of users.
I've had to debug every install of docker for windows that I've done because it doesn't set something up correctly. Usually this involves googling the error message, finding a github thread where people are talking about which builds this affects, and then trying one of three or more powershell commands to fix whichever part of the install failed. In the most recent attempt, the error message told me to enabled virtualization in the BIOS, but it was actually that HyperV had not been enabled properly[1]. It was installed and the UI ran, but if you tried to start any VM, it would fail. I doubt debugging this sort of thing is feasible for an end user.
Docker Toolbox, although less polished, is based on VirtualBox and happily runs without Hyper-V. The only thing I've found missing is the control panel GUI.
