home.social

#vuetify — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #vuetify, aggregated by home.social.

  1. Vuetify is web component framework for Vue and just like #Vue it is independent (so there is no large organisation that pays for most of it). We (@intevation) use #Vuetify in a number of products and thus pay for it voluntarily. It is #FreeSoftware.

    If you and others would pay a small amount, too. They can compensate more contributors and develop faster: github.com/vuetifyjs/vuetify/r :)

  2. 𝗩𝘂𝗲𝘁𝗶𝗳𝘆:

    #Vue #Material #Framework #Vuetify

    thewhale.cc/posts/vuetify

    Material component framework for Vue.js Vuetify is an open source MIT project.

  3. I read the doc and I'm able to show the tooltip OR the popup, but when I try to activate both that doesn't work.... 😓

    #vuetify #vuejs #frontenddeveloper

  4. I've been able to work on Rack Root some more lately, and been spending a lot of time writing tests for the backend. At some point, I'm going to need to make sure I'm covering ALL the code paths, especially the ones that raise exceptions.

    I didn't quite do test-driven development, but I do have most branches of the logic covered for a lot of scenarios. I'm up to 67 tests so far, but I'm sure I'll be over 100 once I add more functionality like associating IPs to devices.

    For now though, I'm finally getting to write some of the frontend code to handle DHCP ranges on a given subnet. It does feel good to get back into that code.

    #programming #rackroot #python #pytest #opensource #fastapi #vuetify

  5. Search results are working now, all the way through to the front end!

    I was curious if I needed to worry about HTTP encoding/decoding of things like spaces/%20, but it looks like everything from the frontend to the backend is helping me with all of that. Search results are coming back as expected, though notably not partial string matches. To find the string DS414 for example, you need the whole DS414 and not just 'DS', which isn't the behavior I want. That'll be the next thing to fix.

    I am also going to need to fix how the backend is talking to the database, which may mean fixing all of the fields to be lowercase/snake_case instead of camelCase. I discovered that when I was working on the triggers for finding these search results. My preference would be to name the database field somewhere in the Column(...) definition instead of refactoring most of my API calls, but we'll see what SQLAlchemy has for me there.

    Then I'll add search support for networking/DHCP and I can get past this hurdle.

    #http #programming #vuetify #fastapi #postgres #sqlalchemy #rackroot #homelab

  6. Rack Root update: tonight I finally got the search page working and passing parameters the way I need it to. There's a search box in the top right hand corner that will take in a given string and (eventually) go ask the API for objects that match the search terms.

    This took a while to put together since entering a search term will redirect you to `/search?q=foo` and that renders properly the first time. With Vuetify however, if you enter another search term while on that page, the app sees you're already on `/search` and doesn't update the values on the page, even though the search parameter is different.

    The solution was thankfully found in a GitHub issue (linked below) where other people were looking for the same kind of functionality. This also taught me about the Navigation Guards that Vue/Vuetify come with to handle page navigation/movements. The app knows when you're on the same page and will make decisions based on that.

    During my testing I just echoed the search parameter back to the user, but now that the hard part is done, I just need to write the API for it and render that on the frontend. Surely there won't be any complications with asking the API for multiple different objects back... that'll really test my database and python skills.

    github.com/vuejs/router/issues

    #rackroot #programming #homelab #justkeeplearning #vuetify #webdev #developer #fastapi #python

  7. It's been a while since I've posted an update for Rack Root, but I've actually made some progress on it lately.

    I've finished my refactor to use SQLAlchemy for the database connections and also (finally) figured out how I want to join tables together and relate things.

    I also changed some API endpoints. For example, if you look for /network/$id/gateway and there's no gateway, you get a 404. I also changed the UX around gateways. When you make a new network, there's no gateway assigned, so that part of the page has a green + icon. When you set a gateway, that icon is now a red delete icon. Those update the field and icon dynamically without having to refresh the whole page.

    The new networks page also will look at the result and see if you got an HTTP 201. If so, you get redirected to the new page. Else, you get an error message. I'm not sure if I want to add more detail to that, it would require the frontend to parse and guess what went wrong. Maybe that's an assignment for another day.

    Finally, there's a new Delete network button on the network detail page.

    #rackroot #homelab #vuetify #fastapi #sqlalchemy #frontend #backend #fullstack #pytest

  8. CW: maybe minimal spoilers for MCU "Infinity Saga" movies

    "But to watch #AgathaAllAlong you should've seen #WandaVision, and to understand what's happening there, you shoud've seen a bunch of #MCU movies."

    "Okay, which ones?"

    "Well…" *hacks together a #Vuetify application* "At least those with the exclamation mark."

    (Keep in mind I'm no designer. And no, I don't have a link, this is a HTML file on my local machine. Also, characters are selected based on their relevance for Endgame or WandaVision.)

  9. Turns out, updating the front end of Rack Root was way faster than the backend, this time around.

    Tonight, I fixed the API calls for the network details page and also added summary counts for IPAM utilization. I decided I was most interested in how many IPs were available and how many were allocated to DHCP.

    I'm not sure if Vuetify has a visualization I can use for this, but the closest thing to what I'm looking for is a horizontal bar with different segments for each type, sized to the percentages of each kind of IP status. If I have 50 DHCP IPs on a /24 network, then roughly 20% of the bar should be colorized to reflect that.

    After that, I'm not sure if I'll tackle the DHCP side yet or start capturing details on associated NICs from a device. Either way, that's a whole bunch more relationships to plan out in the database. And now that I have a working example of foreign key relationships, it should be easier.

    #rackroot #programming #webdev #frontend #backend #vuetify #fastapi #homelab

  10. Gateway stuff is done for now, so it's time to work on the DHCP range data.

    A network can have 0..n DHCP ranges and each DHCP range should be editable with the CRUD operations.

    C - create: add a new DHCP range, make sure it doesn't overlap with another DHCP range already present on this network. All IPs should be in range, too.
    R - read: render DHCP range information and overall IPAM utilization of the network. A DHCP range covering 200 IPs on a /24 should, for example, show roughly 80% of the IPs are used. Vuetify has UI elements to render stuff like this.
    U - update: change data about the range such as the start/end addresses, name, or description.
    D - delete: remove a DHCP range <--> network association and the associated record(s) from the db.

    Validations:
    DHCP range doesn't overlap other IPs in use on the network, such as the gateway, static IP assignments on that network (which I haven't even gotten to), or other DHCP ranges.

    There's going to be a LOT of testing to go into this and I think that's why I like this kind of stuff. It forces me to think of all the use cases, write tests, add code, and balance all of it together.

    #rackroot #programming #networking #fastapi #python #webdev #fullstackdevelopment #fullstack #vuetify #databasedesign

  11. I got the gateway update working tonight and decided to shift all the validation logic to the backend, which also had a side effect of simplifying my code.

    Before I was on the front end writing javascript logic for whether the gateway was being set or cleared and then I would also need to write code for how to handle all the combinations. Now, I have one API endpoint at /networks/{id}/gateway where an HTTP POST can be submitted and that either passes or fails.

    If someone puts in an invalid IP address, or the IP address is not a usable IP in the subnet, it won't be accepted and an error message is shown on the page. HTTP 500 is returned and Vuetify can pick that up to show an error message for me. Once valid input is submitted, the error will go away and the user will see the gateway updated to the proper value.

    If someone adds a gateway when there wasn't one before, or updates the address to something else, then the IP will be processed and updated as long as it's valid.

    #rackroot #programming #vuetify #python #ipam #fastapi #webdev #fullstack

  12. I decided to change the add/remove functionality on the gateway field and replace it simply with a wrench icon that lets you edit the value.

    In the Vuetify code, this gets around me having to check the logic of whether the value is populated or not and rendering the right color button. I think it fits better with the code, input form modal, and other parts of the page. Accordingly, I changed the color to yellow.

    I'm still working on some of the javascript for it and next time, I need to:

    a) detect if a value is in the form and if so apply it to [POST] /networks/{id}/gateway
    b) if no value is in the form, call [DELETE] on /networks/{id}/gateway
    c) add better error handling so that invalid values bump the user back to the input modal with a relevant message
    d) detect that someone didn't put in the network address or broadcast address (backend only, builds on c)

    If someone puts a gateway in that's not in the same network, it will be rejected by the backend, but the front end needs to also show something useful. That's its job!

    #rackroot #webdev #programming #vuetify #javascript #fastapi #python #homelab #ui #ux

  13. Just published my latest blog post: Is This Thing On? Yeah!

    It's been a while since I've written a blog post so I decided to get some thoughts out and introduce Rack Root to my readers over there.

    medium.com/@a.j.longchamps/is-

    #homelab #blogging #contentcreation #webdev #vuetify #linux #fastapi #rackroot

  14. Success - I have a rough design in place for the network detail page. This will show things like the network name, IP/SM/GW details, VLAN, description, and eventually a table of 0..n DHCP ranges.

    I also have a button to add or delete the gateway so that the gateway can be updated as needed. The gateway is optional when the network is created and the button renders based on that field. Next time I work on this, I'll add a text modal to go with the "add" button.

    #programming #homelab #rackroot #vuetify #python #fastapi #pytest #webdev #webdesign

  15. I'm still working on this and now that all the holiday stuff is over with, I can finally spend some time on it.

    I added a gateway field to the existing production database, thanks to Atlas. This let me add a field to the table and make sure all the existing data came over.

    Now that the gateway field is there, I got the backend code done and tests are all passing.

    For the front end, I have a design in mind for how to lay it out, now I just get to figure out how to get there.

    #programming #webdev #backend #python #fastapi #vuetify #rackroot #homelab

    atlasgo.io

  16. Manually updated the database for tonight with a database browser for the sake of some progress. I managed to get the new network page, network detail page, and all networks table all working together. Here's a screenshot of my new network form.

    This also lays the essential groundwork where I can start to track some IP allocations. At the very least, I want to track the gateway address, DHCP ranges, and static allocations. Then once I have the data, visualize it in a nice way.

    I should be able to find Vuetify elements that can visualize and colorize this on the front end.

    On the back end, I'll figure out some kind of relationship scheme for this that makes sense.

    #rackroot #programming #vuetify #homelab #webdev #frontend #backend #fastapi

  17. Me: copies code from the new Item page that I posted about recently into the new Networks page.

    Also me: why isn't the "Add New Network" button submitting the form and POSTing to the backend like it should?

    Also me: tries to make a new Item entry and that also does not POST to the backend, it just does noting.

    Well, it did what I (accidentally) told it to do: nothing. Looks like I need to move the Submit button into the form itself to get it to work.

    This is why constant testing is essential for this project!

    #rackroot #homelab #programming #testing #oops #vuetify

  18. Writing some of the IPAM implementation is probably going to be the hardest part of this project so far, and I haven't even gotten to the device <-> network relationship(s) yet.

    So far in my IPAM code, I have checks for invalid IP ranges and uniqueness, though I'm sure I'm also missing some corner cases.

    Then on the front end side, I plan to visualize network usage which can include assigned static IPs, DHCP ranges, gateway/router designations, etc.

    I'm hoping that coding it as I go through the frontend and backend will help me properly structure everything, figure out which relationships I need to pull in, and establish the design for my API.

    I'm also very happy that I have pytest tests to go with my code. I'm writing those every time I add a new section and it pays off.

    #rackroot #programming #python #vuetify #fastapi #testing #pytest #testdrivendevelopment

  19. The goal for Rack Root is to inventory my home lab and learn some web dev (FE+BE) along the way. I'm now at the point where I think I'll have the biggest challenge: IPAM / networking data.

    I'm anticipating that this part will be the most complex because of all the relationships. This is also going to test my API and database design skills, to say nothing of the front end design.

    At the start, I'm going to need a good IPv4 address handler library, ways to CRUD network segments, CRUD DHCP ranges, assign static IPs to devices, and similar.

    I also will have the data to generate visualizations of IP address usage, and plan to do that at some point.

    I fully expect to take advantage of things like Vuetify 3's v-card element which should help with some nifty graphical layouts.

    #rackroot #programming #applicationdesign #webdev #backend #fastapi #frontend #vuetify

  20. Finished the NewItem.vue page for now with a better layout, date pickers for purchase date and warranty expiration, and a placeholder for devices on the network.

    My next plan is to start designing the networking piece of Rack Root and figure out which pieces I'll need to put in place. This will include the network zone, DHCP ranges, and subnet mask info. Devices on the network can be DHCP or static which is data I plan to track.

    Items will have the ability to use 0..n network interfaces which accounts for things not on the network such as hard drives, single-NIC devices such as laptops, and multi-NIC devices such as network devices. All of that can go into the database.

    By the time it's done, I should have the data to generate a pretty good picture of the network layout such as DHCP range utilization and IP utilization. Somewhere along the way I'll need to figure out subnet math, too. Yay.

    #homelab #programming #vuetify #rackroot #fastapi #frontend #sideproject #networking #webdev

  21. Now to the new item functionality.

    First screenshot shows a summary of test values in the table, and the date is formatted on the frontend so it looks the way I want.

    Second screenshot shows the new item page which is definitely still a work in progress. I have a lot of functionality to add to this one, and figure out what layout I want to use for it. I'm using things like v-field, v-textarea, and v-date-picker for these elements. The buttons are of course using v-btn.

    The last screenshot shows the item detail page and this design is definitely not final. I'm not even showing the notes or descriptions fields in this view. I really should sketch out some things I want to do in order to use this the way I want.

    #rackroot #programming #opensource #webdev #vuetify #fastapi #ux #frontend #backend #sideproject

  22. And now for some screenshots.

    First screenshot shows the landing page with basic summaries.

    Second screenshot shows the new device type tab on the settings page.

    Third screenshot shows another tab I setup for export/import functionality. That one will be interesting to write, for sure.

    #rackroot #programming #opensource #webdev #vuetify #fastapi #ux #frontend #backend #sideproject

  23. Well, it's been a month or so since I've posted about Rack Root so here's what I've changed/learned about.

    It was easier for me to use DateTime than Date, even if I just want to hold a Date field. I also started to really build out some of the more dynamic functionality.

    Device types can now be defined on the setting page, tab 1 and I'm using a modal textbox that pops up when you go to add a new item. All that needs is a name so a model makes a lot of sense for that.

    When making a new item, the device types are pulled over dynamically and displayed as human-friendly names in a drop down. In the code and going to the back end, it's all using the ID. This field is also nullable in case the device type gets deleted, it won't throw as many exceptions.

    I also wrote up the item detail page, though both the new item page and item detail page tell me that I need better UX design / more layout experience. This stuff isn't easy!

    Finally on the design side of things, I've added a couple dynamic boxes to the landing page that show how many items and device types are defined. This is another part of the site I'll work to design more as I go.

    I'm sure I will find something that looks good and functions the way I want – I just need to get there. And I can tell by where I am now that this project will keep me busy for as long as I want it to.

    #rackroot #opensource #webdev #vuetify #fastapi #ux #frontend #backend #sideproject

  24. I appreciate that with Vue/Vuetify, I'm able to do that whole Settings page dynamically and I did this in under 50 lines of code. Of course I'm heavily relying on imports and all the libraries underneath, but this just makes it so easy once you know how things work and which levers to pull in order to adjust appearance.

    I was able to work on this layout and even add tabs to it in just a couple of hours.

    #rackroot #webdev #frontend #vue #vuetify

  25. Tonight's short update - I added a new table to the database to store device types, associated HTTP GET all device types, HTTP POST create device type, and a settings page in the app with tabs to view the device types.

    This gave me more practice in laying out pages in Vue/Vuetify, using classes to control the layout, height, width, etc.

    My next update has to be more focused on the backend and testing since I don't have that many tests going on there now.

    Below is a screenshot of the table as it stands now and I'll link to the frontend in my latest commit here: github.com/alongchamps/rack-ro

    #rackroot #webdev #programming #frontend #backend #vue #vuetify #vite #javascript

  26. I finally have a functional foundation on which to build the front end for Rack Root. For some reason when I was working on it the past few days, the front end code was not cooperating. I reinitialized the project, copied in my existing (previously functional files) and the frontend would just complain about invalid javascript.

    According to Visual Studio Code, everything looked good. I copied the relevant javascript out and it still looked good, no syntax errors. According to my console, there was a javascript error at the end of the </script> tag in the .vue file.

    Whatever it was, I re-typed the relevant bits/pieces of my code, checked everything incrementally along the way, and got it back to working again.

    Now I can start to write more of the back end code, get it all tested, write the front end to go with it, and so on. Repeat until 'done' ;)

    #rackroot #webdev #programming #python #fastapi #vue #vuetify #vite

  27. Ever stumbled upon those form fields that suggest options in a drop-down as you type, like when you’re entering addresses? Turns out, making those aren’t as tough as you’d think! Today, I’m gonna walk you through three cool ways to pull it off using Vue.js. Let’s dive in!

    Vuetify

    If you are a Vue developer, you have likely used Vuetify.  It is an open-source UI library that offers Vue Components for all sorts of things.  One of those things just happens to be Autocompletes.

    See the Pen
    Autocomplete -- Vuetify
    by Joe Steinbring (@steinbring)
    on CodePen.

    Last week, I spoke about creating a repository of data for coding examples.  The first one is a list of counties in the state of Wisconsin.  In this example, the values from the API are stored in a counties array, the value that you entered into the input is stored in a selectedCounty variable, and the fetchCounties method fetches the values from the API.  Thanks to v-autocomplete component, it is super easy using Vuetify.

    Shoelace

    Shoelace (now known as Web Awesome) doesn’t have a built-in autocomplete element but there is a stretch-goal on their kickstarter to add one.  That means that we need to build the functionality ourselves.

    See the Pen
    Autocomplete -- Shoelace
    by Joe Steinbring (@steinbring)
    on CodePen.

    Our Shoelace version has a filteredCounties variable so that we can control what is shown in the suggestions and a selectCounty method to let the user click on one of the suggestions.

    Plain HTML and CSS

    We have already established that Shoelace doesn’t have an autocomplete but neither does Bulma or Bootstrap.  So, I figured that we would try a pure HTML and CSS autocomplete.

    See the Pen
    Autocomplete -- HTML
    by Joe Steinbring (@steinbring)
    on CodePen.

    This is very similar to out Shoelace example but with some extra CSS on the input.  You might be wondering about that autocomplete attribute on the input.  It is a different type of autocomplete.  The autocomplete attribute specifies if browsers should try to predict the value of an input field or not.  You still need to roll-your-own for the suggestions.

    https://jws.news/2024/how-to-impliment-an-autocomplete-using-vue/

    #Autocomplete #HTML #JavaScript #VueJs #Vuetify #WebAwesome