I started working on a WYSIWYG CMS Editor for Web-Applications and Websites.
Based on my experiences, I think there is something missing in the market for content creators / editors for WebApps (with landing pages etc.) and websites. There are many headless CMSs available but many are lacking a simple editing experience.
I want to make it easy for the developer to integrate it into a project (using React for example) - but also make it really easy for the content creator to be more independent of developers - while keeping UI constraints etc.
I choose to build a native iOS and MacOS App with SwiftUI that basically provides all editing UI as native components instead of using HTML/CSS - Basically an overlay on top of the website that let's you control the components and website grid/layout. It's mainly a proof of concept and for me a way to learn SwiftUI :)
There are many Website builders that provide great editing UIs (e.g. Webflow, Builder.io etc.), but I feel a native app, especially on iPad OS could provide benefits and it's a nice challenge :)
I ordered one :D. I love the size of the car, it's small enough to navigate in a town and AC charging speed is high (22 kw, no one else, besides a SMART offers this in this price range). I can't charge at home (as I live in an appartment in the city) and I don't want to wait 6 hours for a full charge. Fast chargers ( >= 50kw) inside towns in Germany are (still) rare and there are more 22kw chargers available around me, also free ones at supermarkets. I occasionally drive more then 500 km, but maybe 3 times per year, and then I would propably take the train anyway.
I love your songs :) Thank you!! <3 And you defnitly popped up on discover weekly :D. I usually star songs that I like there, and / or order them in my custom playlists.
I used redux before switching to Apollo and a query parameters / routing based state management. In Web Applications especially, it makes sense to couple global state to URLs. It makes the page and the current state shareable and brings value (like tabs, filters, pagination etc.). I developed a library based on zustand and immer for this case (called Geschichte). It’s open source https://github.com/BowlingX/geschichte
Most of the use cases I can solve with that, the rest is usually either forms (covered by formik, final-form etc), async loading of data (Apollo) or local state and animations.
I am using postgraphile in library mode with keycloak and passport.js (an open source project https://www.keycloak.org/) instead of auth0 and it works great.
For websites this seems ok for me, but for apps that run inside wkwebview, I think there should be more control about this behavior. You can't zoom normal apps so this would make the Usebility properly worse or unexpected.
Finally they managed to remove the weird intelligent selection behavior in safari!!! (The one that unpredictable marks blocks or the whole website). Thank you apple :)
They also ignore any viewport meta data so you can always zoom. My Cordova app doesn't like this :( I hope it can be disabled for WKWebView programmatically
My cordova application's history management stopped "randomly" working with "SecurityError: DOM Exception 18" exceptions. The reason (mentioned in the link I found) is a limit that has been recently introduced by apple to prevent a security flaw.
It doesn't make any sense for me. This might break a lot of applications and Websites that rely on the History API.
I recently open-sourced a pattern-library/framework that uses mainly FlexBox to arrange/layout items: http://bowlingx.github.io/flexcss/. FlexBox for me was especially useful for big forms while using less markup.
That's correct. But it is possible to specify a context container where the highlighting is executed so if you change parts of the document (like around this container) it doesn't change the relative path.
Example:
<html>
<body>
<article id="myContextContainer">
<p>...</p>
</article>
</body>
</html>
If you add or change words and paragraphs of course, that would make the highlighting unstable. You could also restrict the marking to a specific paragraph only (and set the context accordingly). It always depends on the application this library is used for. But if anyone has a good idea how to compensate that I'm open for suggestions :)
Based on my experiences, I think there is something missing in the market for content creators / editors for WebApps (with landing pages etc.) and websites. There are many headless CMSs available but many are lacking a simple editing experience.
I want to make it easy for the developer to integrate it into a project (using React for example) - but also make it really easy for the content creator to be more independent of developers - while keeping UI constraints etc.
I choose to build a native iOS and MacOS App with SwiftUI that basically provides all editing UI as native components instead of using HTML/CSS - Basically an overlay on top of the website that let's you control the components and website grid/layout. It's mainly a proof of concept and for me a way to learn SwiftUI :)
There are many Website builders that provide great editing UIs (e.g. Webflow, Builder.io etc.), but I feel a native app, especially on iPad OS could provide benefits and it's a nice challenge :)