Announcing Newlogic UI 4
January 28, 2025
This version is a major step in Newlogic UI, meta-framework which focuses on modern and fast backend driven web applications.
The framework is now split into various packages, 6 internal and 2 external, all that we worked on. A lot of work has been done, and the framework has been overhauled from the ground up.
New Documentation
The latest version of Newlogic UI introduces revamped documentation, still work in progress though! This ensures that developers can more easily navigate and access resources needed to build websites and applications. It focuses on clearer structure, concise examples, and an intuitive layout, making the onboarding process more seamless than ever.
Meta framework
Newlogic UI 4 is now a complex meta-framework that follows common standards. This allows developers to build modular, scalable websites and applications. With improvements in flexibility and performance, the framework is now split into multiple internal and external packages to streamline development processes.
For us, it's the most powerful framework for Nette backend driven websites and applications.
Internal Packages
@newlogic-digital/cookieconsent-js
It was introduced already in version 3.7
, but now is considered stable and provides an easy-to-implement solution for managing scripts depending on cookie consent.
@newlogic-digital/utils-js
It was introduced already in version 3.7
, but now is considered stable and provides a collection of JavaScript functions to simplify common development tasks.
@newlogic-digital/stimulus-components
New package introduced in version 4.0
, provides various pre-built components that are better fit excluded from Newlogic UI itself. This provides an overall better maintainability across projects.
@newlogic-digital/naja-extensions
New package introduced in version 4.0
, externalizes major naja
initialization configuration and extensions into a separate package. This provides an overall better maintainability across projects.
@newlogic-digital/swup-plugins
New package introduced in version 4.0
, externalizes major swup initialization configuration and plugins into a separate package. This provides an overall better maintainability across projects.
New Structure
Resource files are still located in the /src
directory. But at the subdirectory level, there are major changes. Previously, the components were organized into subfolders such as Components
, Layout
, Sections
and Ui
.
This is now unified into one directory - components
.
We are now using a well-established structure similar to Nuxt or Next.
- components
- we recommend the following best practices with structure and naming as mentioned at Nuxt
- furthermore, it's recommended to use groups similar to Next's route groups for better organization
- composables
- here comes your JavaScript composables, mainly used for reusable functionality you want to use elsewhere, similar to Nuxt
- utils
- here comes any JavaScript utility functions or stylesheet utility classes you want to use throughout your application, similar to Nuxt
This overall simplifies development processes and overall project structure.
Learn more at docs/usage
Backend Integration
Since version 3.0
, the library was a great frontend companion for Nette Framework also including naja out of the box for seamless snippets.
Now in version 4.0
is strengthened even more, with @newlogic-digital/naja-extensions
and using naja
for fetching remote components like dialogs
or popovers
.
This allows redrawing snippets for these components seamlessly, which was not possible previously.
The meta-framework is also backend framework-agnostic, so it's possible to drop naja
or use a completely different backend framework such as Laravel or Rails.
Winduum 2.x
Winduum was previously introduced in version 3.4
and it's integration was steadily added in the following versions. Now it's fully integrated with the new revamped version 2.0
winduum-stimulus
This version introduces also the winduum-stimulus
package, which provides code for most of the JavaScript components. Which externalizes most of the code needed for each component included in Newlogic UI.
import { useStimulus } from '../../composables/stimulus.js'
import { Button } from 'winduum-stimulus/components/button/index.js'
useStimulus.register('x-button', Button)
This provides an overall better maintainability across projects.
Single Component Prefix
Previously Winduum included various prefixes for different types of components, such as c-
and ui-
. This is now simplified into one single prefix x-
, so it's clear that everything which uses prefixes class is a component.
Naming is similar to Laravel blade components or Alpine.js.
<button class="x-button">
Button
</button>
Invoke Actions
Most of the logic is now done directly in the component. So we are introducing API similar to proposed invokeaction
and invoketarget
.
- previously -
data-action="lib-dialog#show"
- now -
data-invoke-action="x-dialog#show"
So instead, you are now calling the show meathod directly on the component. You are now also able to show existing dialogs, rather than only fetched ones.
<button
data-invoke-action="x-dialog#show"
data-invoke-target="#dialogElement"
>
This is now also deeply integrated with data-naja
, which allows redrawing dialogs via snippets.
<button
data-naja="invoke once"
data-naja-url="/fetch"
data-invoke-action="x-dialog#show"
>
State Attributes
Previously, most of the state was done via classes. In version 2.0
this was unified to data attributes, which is more TailwindCSS compatible, and most of the frameworks use the same system.
1.x
<button class="ui-btn loading [&.loading]:pointer-events-none">
Button
</button>
2.x (tw v3)
<button class="x-button data-[loading]:pointer-events-none" data-loading>
Button
</button>
2.x (tw v4)
<button class="x-button data-loading:pointer-events-none" data-loading>
Button
</button>
Accessible Web Standards
Winduum is all about web standards and accessible components that can be used in any framework. For Newlogic UI it was a major step to transition to accessible components.
This ensures that future projects are ready for European Accessibility Act.
View Transitions API
Version 4.0
still includes Swup, but now the browser support for View Transition API is getting better! Chrome supports it fully, and Safari 18
partly - with full support in 18.2
.
Which means that for the pages that use data-no-swup
, the fallback is native transitions! Or you could drop Swup in your project completely and use native transitions, depends on the project.
TailwindCSS 4 Support
TailwindCSS 4 is coming next year, and Winduum 2 uses syntax that is compatible with this future release.
We are still using the version 3.x
, but the upcoming switch to the new version will be really easy. Version 4.x
is a major upgrade and introduces major changes and improvements, learn more about it in the official blog post.
ESLint 9 and neostandard
Newlogic UI 4 also introduces support for ESLint 9, also including new neostandard config.
Neostandard is the spiritual successor to the standardjs JavaScript style guide. It replaces unsupported eslint-config-standard
.
The support was also backported into version 3.7
.
Vite 6
Newlogic UI 4 also introduces support for Vite 6.
The support was also backported into version 3.8
.
Newlogic Core 3
Vituum
Initial version was introduced in 3.2
, and we have added a stable version in 3.5
.
Vituum 1.x
continues adding seamless fast prototyping with template engines in Vite also in version 4.0
. Yes, latte in JavaScript is a thing!
Better Browser Support
Each Newlogic UI now includes following browserlist
entry in package.json
.
{
"browserslist": [
"> 1%",
"last 2 major versions",
"not kaios > 0",
"not dead"
]
}
This entry is also included in the build step and ensures that the output includes browser supported styles and scripts.
Emails Are Simplified
We've changed how email styles are inlined on backend. So the code for email generation for backend was removed. Emails on backend are using also Juice via PHP shell command, so PostHTML and other stuff is not needed anymore.
This release also includes new simple TailwindCSS common email template and uses the same directory structure as regular templates.
Removals
air-datepicker
- it has been removed in favor of build-in solutions, but it's planned to bring it back as optional component package@simonwep/pickr
- it has been removed in favor of build-in solutions, currently it's not planned to bring it back- included docs and templates - the initial repository now includes only the bare minimum, focusing instead on leaner and more modern setup
Migrating from the v4-beta
- replace
devDependencies
with stable version ones - update winduum to v2.1
- migrate changed css custom properties from winduum v2.1
- ensure that
./
prefix is in css import paths - update css
src/styles/utils
layers - update
naja.js
with the stable one